The Deployment Bunny

OS Deployment, Virtualization, Microsoft based Infrastructure…

  • about.me

    Mikael Nystrom

    Mikael Nystrom

    OS Deployment Geek, Virtualization and System Center

    Mikael Nystrom is a Principal Architect at TrueSec

  • Archives

  • Meta

Posts Tagged ‘Windows Server 2008 R2’

PowerShell is King–Convert Windows Server Editions during OS Deployment (MDT/LiteTouch)

Posted by Mikael Nystrom on July 2, 2014

Yesterday I posted a simple UI based PowerShell script that allows the local administrator of the server to change the Windows Edition. That is is a nice to have function, but what if you would like to do that during the deployment of the server instead of after. This way you can have two task sequences, one for Standard and one for datacenter but just have one WIM file (also means one reference image). For the same reasons I mentioned in the previous post,  I have created some scripts for this.

You can read the previous post on the UI method here http://deploymentbunny.com/2014/07/01/powershell-is-kingconvert-windows-server-editions-using-a-ui-based-powershell-script/

All three options here are using the same base logic with the same kind of option. Instead of defining every different “upgrade” , I decided to have just 2, NEXT and TOP. When TOP is selected as an option it will upgrade to the TOP Edition, in other words Datacenter. When NEXT is selected, it will do the NEXT level. That means that a standard will be datacenter, unless it is a 2008 r2, then a standard will be enterprise. Evaluations will be the “same, so a standard evaluation, will be a standard . In a bit more detail, this is what the scripts actually do…

What kind of conversion can the scripts perform?

Source OS   UpgradeLevel Destination OS
Windows Server 2008 R2 Standard to NEXT Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Standard   TOP Windows Server 2008 R2 Datacenter
Windows Server 2008 R2 Enterprise   NEXT/TOP Windows Server 2008 R2 Datacenter
Windows Server 2012 Standard Evaluation   NEXT Windows Server 2012 Standard
Windows Server 2012 Standard Evaluation   TOP Windows Server 2012 Datacenter
Windows Server 2012 Standard   NEXT/TOP Windows Server 2012 Datacenter
Windows Server 2012 R2 Standard Evaluation   NEXT Windows Server 2012 R2 Standard
Windows Server 2012 R2 Standard Evaluation   TOP Windows Server 2012 R2 Datacenter
Windows Server 2012 R2 Standard   NEXT/TOP Windows Server 2012 R2 Datacenter

 

Option No:1 (VB Script as an Application)

The first option is to use a VBscript and run it as an application, that gives a great logging and integration with the Task Sequence in MDT. The script uses a Custom property called UpgradeLevel (which can be set to either NEXT or TOP) that you needs to be added to CustomSettings.ini

Step By Step, kind of…

Download Script from : http://1drv.ms/TBO9Zw

Add the Custom property UpgradeLevel.

image

Import the Application in the Deployment Workbench.

image

Modify the Task Sequence (add a Set Task Sequence Variable Step)

image

Modify the Task Sequence (Add the Application)

image

Deploy a Server and check the logfile.

image

Option No:2 (PowerShell Script as an Application)

The second option is to use a PowerShell script instead, still running as an application, I added some logic to discover the presence of a Task Sequence, that way logging can end up in the correct location

Step By Step, kind of…

Download Script from : http://1drv.ms/TBOgEn

Add the Custom property UpgradeLevel.

image

Import the Application in the Deployment Workbench

image
The command line is a bit long so here it is in text form
PowerShell.exe -ExecutionPolicy Bypass -File Upgrade-SKU.ps1 -UpgradeLevel %UPGRADELEVEL%

Modify the Task Sequence (add a Set Task Sequence Variable Step)

image

Modify the Task Sequence (Add the Application)

image

Deploy the server and check the logfile.

image

Option No:3 (PowerShell Script in TaskSequence)

The third option is to run it as a PowerShell task Sequence

Step By Step, kind of…

Download Script from :http://1drv.ms/1qjoOAk

Save the script in the scripts folder

Modify the Task Sequence (Run PowerShell script)

image

Modify the Task Sequence (Add a reboot Action)

image

Deploy a server and check the logfile.

image

/mike

Posted in MDT, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 | Tagged: , , | 2 Comments »

PowerShell is King–Convert Windows Server Editions using a UI based PowerShell script

Posted by Mikael Nystrom on July 1, 2014

If possible it is best practices to keep the number of images to a minimum. So, in my line of work I’m building reference images for both client and servers, many of the organization I work with are struggling with the fact that they need to have both old images and new images, both servers and clients and also both 32 and 64 bit. Add all that up you will realize that, hmm, lets see… that will be 9 images to maintain, no, wait, I missed the fact that we also have different editions. Servers have Standard and Datacenter edition, that is three more, or actually its 4 more since Windows Server 2008 R2 have Standard, Enterprise and Datacenter.

Download the script from http://1drv.ms/1lMpr4i

The solution

Since it is possible to upgrade every Windows Server edition (Windows Server 2008 R2 and above) to a higher edition (and that includes evaluation editions to) by changing the product key using DISM.exe it is possible to create reference images with the lowest SKU(Edition) that your organization needs and upgrade during the deployment or as this blog post is about, after the OS has been deployed. Internally for us this is great since we are running many proof of concept, labs, tests and such and many cases. I gave up telling/explaining for our internal staff on how to do this, ending up with a script that is “user-friendly”.

To be able to change edition, you need to have a product key, and what we do is that we change to the KMS client key, so yes it needs to be activated after it has been modified. You can find all these product keys at TechNet here: http://technet.microsoft.com/en-us/library/jj612867.aspx

What kind of conversion can the script perform?

Windows Server 2008 R2 Standard to Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Standard to Windows Server 2008 R2 Datacenter
Windows Server 2008 R2 Enterprise to Windows Server 2008 R2 Datacenter
Windows Server 2012 Standard Evaluation to Windows Server 2012 Standard
Windows Server 2012 Standard Evaluation to Windows Server 2012 Datacenter
Windows Server 2012 Standard to Windows Server 2012 Datacenter
Windows Server 2012 R2 Standard Evaluation to Windows Server 2012 R2 Standard
Windows Server 2012 R2 Standard Evaluation to Windows Server 2012 R2 Datacenter
Windows Server 2012 R2 Standard to Windows Server 2012 R2 Datacenter

How to use?

Execute the script from an elevated command prompt and select upgrade type.

image
Changing from Windows Server 2008 R2.

image
Changed from Windows Server 2008 R2.

image
Changing from Windows Server 2012 R2 Standard Evaluation.

image
Changing from Windows Server 2012 Standard.

Posted in PowerShell, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 | Tagged: , , , | 1 Comment »

Deployment Geek Week in Redmond – December 12-16, 2011

Posted by Mikael Nystrom on November 22, 2011

It’s time for Johan Arwidmark and me to deliver the “Geek Week”, this is by far the most exiting training I have ever done, it is fun, it is very technical and I have never ever had so many “-Aha, I did not know you could do that?”

The reason why it is so fun for us and in many cases “exiting” for our attendees is that it is “complete”, that means that we cover everything more or less, we start out with general Windows 7 Deployment, ref images, Windows Deployment Services, Microsoft Deployment Toolkit, Lite Touch, Zero touch, Applications, MAP and ACT and that is only the first 2 days and you build most of this. So what will happen next then? Since the world is not perfect and deployment people normally know less of the “Dark Side” (That is Server Side) we start putting up different solutions for app-compat issues, so we will setup System Center Virtual Machine manager, learn Hyper-V, Scripting Hyper-V, Deploy Terminal Servers, Learn GPP/GPO, learn things around File, Print, Cluster, Active Directory and everything that you really need know about. Not only will you learn, you will learn by doing, since you are building the entire infrastructure around this. We also spend time on troubleshooting of course

We normally stay at the same hotel, that means all of us, so is just happens to be a bar there. So after class there will be a bunch of doing down in the hotel to continue the “class” over a drink.

It is hard to describe this event, but at least I tried. We don’t run those events very often so you might want to join in, I’ll guess we will run the next event in the summer of 2012 or even later than that.

Anyway, you can read what other are saying about this here Microsoft Pinpoint

and you can read more and sign up here – http://www.truesec.com/infrastructure/labs/deployment/migration/deployment_geek_week

Really hope to see you there.

/mike

Posted in Deployment, Geek Week, Hyper-V, iSCSI, Lite Touch, MDT, SCCM, SCVMM, Windows 7, Windows Server 2008 R2 | Tagged: , , , , , , | Leave a Comment »

Step-by-Step: Upgrading BIOS during LiteTouch Deployment, for Dell, Hewlett-Packard and Lenovo

Posted by Mikael Nystrom on May 20, 2011

Ok, so here is the short( not really sure this is going to be short by the way, well nothing is perfect) story, once again a customer (Thank you Bill for letting me test fun stuff in your environment!) asked me for a feature that I have done multiple times before, so the task was easy, just upgrade the BIOS when we deploy the machine, so I told them that
–Hey, this is the way to do it and the reply was.
–Sorry, It cannot be done as far as we know, since we have Lenovo and Lenovo does not allow you to run the BIOS firmware update in WinPE.
So it was time to start some thinking. We need to figure out how to create a solid solution and we to do an “all-night-long”. I did not just wanted to fix this customers issue, I want some kind of universal solution that will work on any hardware, client, type, vendor and so on. So I fired up my idea-engine and bang, there it was. I had a plan and a solution that would work, should only take a couple of minutes, kind of. At least that was the idea
(Just a quick note: I did not have the capability to test the Dell part of the script since I don’t have a Dell computer (For some reason most vendors are very polite and give me things to play with, but Dell obviously have an other agenda and I cannot afford to buy a Dell computer just to be able to write blog posts. Anyone has a used Dell that you are willing to give away for scientific experiments by the way? However, it should work, if it doesn’t, ping me)

Here is what we need:

  • It should work with any vendor in the same way
  • It should work with both servers and clients
  • It should do some serious logging
  • I should be able reuse some part of the code in other scenarios
  • It should work in WinPE

…Six hours later, Non-Stop “NCIS” at the hotel room, numerous reboots and massive amount of Coke and the solution was done and here is how it works.

We need information to make decisions!

We really need some variables to work with and it would be possible to use just one simple script to solve the problem, but then I started to think a bit, and.. It would be nice to do this  just a bit “Michael Niehaus / Keith Garner style”.

That way I could use these variables for other purposes then just this and I would in the long run have a nice UserExit Script that will collect all kinds of variables to make the deployment even more dynamically then it already is (Why?, Because I can of course…). Now it would be nice if all vendors use the same location in WMI to store information for the same thing, but that’s not going to happen, trust me, the British Empire will shift over to driving on the right side of the road and the US will start using the metric system before that happens, not very likely in other words. So we need to collect the following so that we later on can use BIOS information to determine what version we have and if it should be upgraded or not

  • From WIN32_BIOS we need SMBIOSBIOSVersion (this will be captured as SMBIOSBIOSVersion)
  • From WIN32_BIOS we need Version (this will be captured as BIOSVersion)
  • From Win32_ComputerSystemProduct we need Version (this will be captured as ProductVersion)

This way, we can use different ´properties and variables for different systems and that is pretty nice.

How will we use the different variables?

Well, by combing them differently we will be able to use them in different combinations to get what we need, here is how we will use them

  • Dell = SMBIOSBIOSVersion + Make + Model
  • Hewlett-Packard = BIOSVersion + Make + Model
  • LENOVO = SMBIOSBIOSVersion + Make + ProductVersion

Now, we can use these properties for this purpose, but you can also use these for other purposes, like driver handling, rules for applications and much more. There is also possible to combine this with the ModelAlias userexit script if you feel for it.

Using a user exit script is the solution to get this data

A user exit script is just a simple piece of VB script that runs as a part of the gather process when MDT reads the customsettings.ini file. So we need to create the ZTITheUserExit.vbs script and put that in the Scripts folder and then we need to update the CustomSettings.ini file so that it is used. You can put the execution of the user exit script basically anywhere in the priority, but I prefer to have a separate section called [Init] where I run everything instead of using default, since default in a production environment seems to be ending up as the last priority, time to stop writing and show you how it should look like:

[Settings]
Priority=Init, Default
Properties=BIOSVersion, SMBIOSBIOSVersion, ProductVersion

[Init]
SMBIOSBIOSVersion=#SetSMBIOSBIOSVersion()#
BIOSVersion=#SetBIOSVersion()#
ProductVersion=#SetProductVersion()#
UserExit=ZTITheUserExit.vbs

[Default]
OSInstall=Y

As you can see, the first thing that will happen when MDT starts reading the customsettings.ini file it finds the section init and it the jumps to that section in the file where it will discover that it needs to run ZTITheUserExit.vbs and that it will be three functions in the script that should return the values into BIOSVersion, SMBBIOSBIOSVersion and ProductVersion. After this has been executed you can now use for example  %BIOSVersion% in the same way as other properties such as %Make%, %Model% if you like. My guess right now is that you now would like to see the script, right? So, here it is, just copy the content and save as ZTITheUserExit.vbs in the scripts folder

ZTITheUserExit.vbs


Function UserExit(sType, sWhen, sDetail, bSkip)
    oLogging.CreateEntry “UserExit: Running Script: ” & sType & ” ” & sWhen & ” ” & sDetail, LogTypeInfo
    UserExit = Success
End Function

Function SetSMBIOSBIOSVersion()
    oLogging.CreateEntry “UserExit: Running Function SetSMBIOSBIOSVersion : ” & sType & ” ” & sWhen & ” ” & sDetail, LogTypeInfo
    Dim objWMI
    Dim objResults
    Dim objInstance
    Dim SMBIOSBIOSVersion
   
    Set objWMI = GetObject(“winmgmts:”)
    Set objResults = objWMI.ExecQuery(“SELECT * FROM Win32_BIOS”)
        If Err then
        oLogging.CreateEntry “Error querying Win32_BIOS: ” & Err.Description & ” (” & Err.Number & “)”, LogTypeError
    Else
        For each objInstance in objResults
            If Not IsNull(objInstance.SMBIOSBIOSVersion) Then
                    SMBIOSBIOSVersion = Trim(objInstance.SMBIOSBIOSVersion)
            End If
        Next
    End If
    SetSMBIOSBIOSVersion = SMBIOSBIOSVersion
    oLogging.CreateEntry “UserExit: Result: ” & SetSMBIOSBIOSVersion, LogTypeInfo
End Function

Function SetBIOSVersion()
    oLogging.CreateEntry “UserExit: Running Function SetBIOSVersion : ” & sType & ” ” & sWhen & ” ” & sDetail, LogTypeInfo
    Dim objWMI
    Dim objResults
    Dim objInstance
    Dim BIOSVersion
   
    Set objWMI = GetObject(“winmgmts:”)
    Set objResults = objWMI.ExecQuery(“SELECT * FROM Win32_BIOS”)
        If Err then
        oLogging.CreateEntry “Error querying Win32_BIOS: ” & Err.Description & ” (” & Err.Number & “)”, LogTypeError
    Else
        For each objInstance in objResults
            If Not IsNull(objInstance.Version) Then
                    BIOSVersion = Trim(objInstance.Version)
            End If
        Next
    End If
    SetBIOSVersion = BIOSVersion
    oLogging.CreateEntry “UserExit: Result: ” & SetBIOSVersion, LogTypeInfo
End Function

Function SetProductVersion()
    oLogging.CreateEntry “UserExit: Running Function SetProductVersion : ” & sType & ” ” & sWhen & ” ” & sDetail, LogTypeInfo
    Dim objWMI
    Dim objResults
    Dim objInstance
    Dim ProductVersion
   
    Set objWMI = GetObject(“winmgmts:”)
    Set objResults = objWMI.ExecQuery(“SELECT * FROM Win32_ComputerSystemProduct”)
        If Err then
        oLogging.CreateEntry “Error querying Win32_BIOS: ” & Err.Description & ” (” & Err.Number & “)”, LogTypeError
    Else
        For each objInstance in objResults
            If Not IsNull(objInstance.Version) Then
                    ProductVersion = Trim(objInstance.Version)
            End If
        Next
    End If
    SetProductVersion = ProductVersion
    oLogging.CreateEntry “UserExit: Result: ” & SetProductVersion, LogTypeInfo
End Function



If we run this script as a part of ZTIgather you should get something similar. So lets just look at the output that the userexit script will generate so that you have some kind of reference:

Determining the INI file to use.
Using COMMAND LINE ARG: Ini file = ..\Control\CustomSettings.ini
Finished determining the INI file to use.
Added new custom property MYCUSTOMPROPERTY
Added new custom property REFTYPE
Added new custom property BIOSVERSION
Added new custom property SMBIOSBIOSVERSION
Added new custom property PRODUCTVERSION
Using from [Settings]: Rule Priority = INIT, TASKSEQUENCEID, DEFAULT
—— Processing the [INIT] section ——
USEREXIT: Running Script: SECTION BEFORE INIT
User exit “C:\MDTLab\Scripts\ZTITheUserExit.vbs” called successfully, skip = False.
USEREXIT: Running Function SetBIOSVersion :
USEREXIT: Result: HPQOEM – f
Property BIOSVERSION is now = HPQOEM – f
Using from [INIT]: BIOSVERSION = HPQOEM – f
USEREXIT: Running Function SetSMBIOSBIOSVersion :
USEREXIT: Result: 68CVD Ver. F.0A
Property SMBIOSBIOSVERSION is now = 68CVD Ver. F.0A
Using from [INIT]: SMBIOSBIOSVERSION = 68CVD Ver. F.0A
USEREXIT: Running Function SetProductVersion :
USEREXIT: Result:
Property PRODUCTVERSION is now =
Using from [INIT]: PRODUCTVERSION =
USEREXIT: Running Script: SECTION AFTER INIT
User exit “C:\MDTLab\Scripts\ZTITheUserExit.vbs” called successfully, skip = False.

Now, lets take a quick look, these are the property values we will get in return on a HP Compaq 8540w (My portable datacenter)

Property BIOSVERSION is now = HPQOEM – f
Property SMBIOSBIOSVERSION is now = 68CVD Ver. F.0A
Property PRODUCTVERSION is now =

Seems to be working. Some explanations before we continue, one thing to notice is that the PRODUCTVERSION is blank and that BIOSVERSION does not give use anything useful, on HP Compaq it is the SMBIOSBIOSVERSION that is the real version of the BIOS, on LENOVO it is BIOSVERSION (You can use SMBIOSBIOSVERSION to, but it also contain “rubbish”. The only reason to use PRODUCTVERSION is that on Lenovo machines that will be the model name, not that nasty number that is extremely unique (so, on a LENOVO T410 it would give you “LENOVO T410” as result

Next step, create a script that can use these variables and then determine if the BIOS has the correct version or if it should be upgraded.

And that is a walk in the park, just create script file called ZTIBIOSUpgrade.wsf, save it the Scripts folder:
The format of the file is somewhat of a school example in the way that it contains extensive logging and contain routines for bailing out if things go bad (script has a certain habit of doing exactly that for some reason. It also have one really strange thing, it has a section for Microsoft Hardware which is Hyper-V, Virtual PC and Virtual Server and now, I’m not insane. I did create that section to verify that it works, since it is some much faster to do snapshots and flip back and forward without re-deploying a physical machine.


<job id=”ZTIBIOSUpgrade”>
<script language=”VBScript” src=”ZTIUtility.vbs”/>
<script language=”VBScript”>

‘//—————————————————————————-
‘// Solution: BIOS Upgrade
‘//
‘// The following values must be populated in the CustomSettings.ini
‘// using a userexit script (ZTITheUserExit.vbs
‘//         – BIOSVersion
‘//         – SMBIOSBIOSVersion
‘//         – ProductVersion
‘// To get these values you also need to execute a userexit script
‘// NOTE: The Section for “Microsoft” is only intended as a test/demo/play,
‘// since the BIOS cannot be updated from within the VM itself.
‘//
‘// Usage: cscript ZTIBIOSUpgrade.wsf[/debug:true]
‘// Version: 1.0 – 4 May 2011 – Mikael Nystrom
‘//
‘// This script is provided “AS IS” with no warranties, confers no rights and
‘// is not supported by the authors
‘//
‘//—————————————————————————-

‘//—————————————————————————-
‘// Global constant and variable declarations
‘//—————————————————————————-

‘//—————————————————————————-
‘//
‘// Global constant and variable declarations
‘//
‘//—————————————————————————-

Option Explicit

Dim iRetVal

‘//—————————————————————————-
‘// End declarations
‘//—————————————————————————-

‘//—————————————————————————-
‘// Main routine
‘//—————————————————————————-

‘On Error Resume Next
iRetVal = ZTIProcess
ProcessResults iRetVal
On Error Goto 0

‘//—————————————————————————
‘//
‘// Function: ZTIProcess()
‘//
‘// Input: None
‘//
‘// Return: Success – 0
‘// Failure – non-zero
‘//
‘// Purpose: Perform main ZTI processing
‘//
‘//—————————————————————————
Function ZTIProcess()

    Dim sMake
    Dim sModel
    Dim sSMBIOSBIOSVersion
    Dim sBIOSVersion
    Dim sExeToRun
    Dim sRefBiosVersion
    Dim sProduct
    Dim sProductVersion
    Dim sOSVersion
    Dim sDeployDrive
    Dim sDeployRoot
    Dim sExecuteCommand
   
    iRetVal = Success
    ZTIProcess = iRetval
   
    sMake = oEnvironment.Item(“Make”)
    sModel = oEnvironment.Item(“Model”)
    sSMBIOSBIOSVersion  = oEnvironment.Item(“SMBIOSBIOSVersion “)
    sBIOSVersion = oEnvironment.Item(“BIOSVersion”)
    sProduct = oEnvironment.Item(“Product”)
    sProductVersion = oEnvironment.Item(“ProductVersion”)
    sOSVersion = oEnvironment.Item(“OSVersion”)
    sDeployDrive = oEnvironment.Item(“DeployDrive”)
    sDeployRoot = oEnvironment.Item(“DeployRoot”)
   
   
    oLogging.CreateEntry “———————————————-“, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – Runninng BIOS Upgrade:   “, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – Make is:                 ” & sMake, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – Model is:                ” & sModel, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – Product is:              ” & sProduct, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – ProductVersion is:       ” & sProductVersion, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – SMBIOSBIOSVersion is:    ” & sSMBIOSBIOSVersion, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – BIOSVersion is:          ” & sBIOSVersion, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – OSVersion is:            ” & sOSVersion, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – DeployDrive:             ” & sDeployDrive, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – DeployRoot:              ” & sDeployRoot, LogTypeInfo
    oLogging.CreateEntry “———————————————-“, LogTypeInfo

    If sOSVersion = “WinPE” Then
    oLogging.CreateEntry “Config-BIOSUpgrade – Running WinPE…”, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – Loading battery monitor…”, LogTypeInfo
    oUtility.RunWithHeartbeat(“drvload \Windows\inf\battery.inf”)
    oLogging.CreateEntry “Config-BIOSUpgrade – Loading battery monitor…Done”, LogTypeInfo’
    Else
    oLogging.CreateEntry “Config-BIOSUpgrade – Not running WinPE…”, LogTypeInfo
    oLogging.CreateEntry “Config-BIOSUpgrade – Not loading battery monitor …”, LogTypeInfo
    End If
   
    Select Case sMake
        Case “Dell Computer Corporation”, “Dell Inc.”, “Dell Computer Corp.”
            oLogging.CreateEntry “Config-BIOSUpgrade – ” & sMake & ” is selected”, LogTypeInfo
            oLogging.CreateEntry “Config-BIOSUpgrade – …searching for BIOS upgrades”, LogTypeInfo
            Select Case sModel
                Case “Latitude D420″ : sExeToRun = “LatitudeD420.cmd ” : sRefBiosVersion=”A06″
                Case Else : sExeToRun = “NA”
            End Select
                If sExeToRun = “NA” Then
                    oLogging.CreateEntry “Config-BIOSUpgrade – No support for ” & sModel, LogTypeInfo
                Elseif sSMBIOSBIOSVersion = sRefBiosVersion Then
                    oLogging.CreateEntry “Config-BIOSUpgrade – No upgrade needed”, LogTypeInfo
                Else
                    oLogging.CreateEntry “Config-BIOSUpgrade – Correct version should be ” & sRefBiosVersion, LogTypeInfo
                    oLogging.CreateEntry “Config-BIOSUpgrade – Upgrading ” & sModel & ” from ” & sSMBIOSBIOSVersion & ” to ” & sRefBiosVersion, LogTypeInfo

                    sExecuteCommand = sDeployDrive & “\BIOSUpgrade\Dell\” & sExeToRun & sDeployDrive
                    oLogging.CreateEntry “Config-BIOSUpgrade – Command to execute ” & sExecuteCommand, LogTypeInfo

                    iRetVal = oUtility.RunWithHeartbeat(sExecuteCommand)
                    if (iRetVal = 0) or (iRetVal = 3010) then
                        ZTIProcess = Success
                    Else
                        ZTIProcess = Failure
                    End If
                End If
 
        Case “Microsoft Corporation”
            oLogging.CreateEntry “Config-BIOSUpgrade – ” & sMake & ” is selected”, LogTypeInfo
            oLogging.CreateEntry “Config-BIOSUpgrade – …searching for BIOS upgrades”, LogTypeInfo
            Select Case sModel
                Case “Virtual Machine” : sExeToRun = “VirtualMachine.cmd ” : sRefBiosVersion=”VRTUAL – 3000920″
                Case Else : sExeToRun = “NA”
            End Select
                If sExeToRun = “NA” Then
                    oLogging.CreateEntry “Config-BIOSUpgrade – No support for ” & sModel, LogTypeInfo
                Elseif sBIOSVersion = sRefBiosVersion Then
                    oLogging.CreateEntry “Config-BIOSUpgrade – No upgrade needed”, LogTypeInfo
                Else
                    oLogging.CreateEntry “Config-BIOSUpgrade – Correct version should be ” & sRefBiosVersion, LogTypeInfo
                    oLogging.CreateEntry “Config-BIOSUpgrade – Upgrading (Well, not really, but what the heck, lets try that…” & sModel & ” from ” & sSMBIOSBIOSVersion & ” to ” & sRefBiosVersion, LogTypeInfo

                    sExecuteCommand = sDeployDrive & “\BIOSUpgrade\Microsoft\” & sExeToRun & sDeployDrive
                    oLogging.CreateEntry “Config-BIOSUpgrade – Command to execute ” & sExecuteCommand, LogTypeInfo

                    iRetVal = oUtility.RunWithHeartbeat(sExecuteCommand)
                    if (iRetVal = 0) or (iRetVal = 3010) then
                        ZTIProcess = Success
                    Else
                        ZTIProcess = Failure
                    End If
                End If

        Case “IBM”, “LENOVO”
            oLogging.CreateEntry “Config-BIOSUpgrade – ” & sMake & ” is selected”, LogTypeInfo
            oLogging.CreateEntry “Config-BIOSUpgrade – …searching for BIOS upgrades”, LogTypeInfo
            Select Case sProductVersion
                Case “ThinkPad T410″ : sExeToRun = “ThinkPadT410.cmd ” : sRefBiosVersion = “LENOVO – 1360″
                Case Else : sExeToRun = “NA”
            End Select
                If sExeToRun = “NA” Then
                    oLogging.CreateEntry “Config-BIOSUpgrade – No support for ” & sProductVersion, LogTypeInfo
                Elseif sBIOSVersion = sRefBiosVersion Then
                    oLogging.CreateEntry “Config-BIOSUpgrade – No upgrade needed”, LogTypeInfo
                Else
                    oLogging.CreateEntry “Config-BIOSUpgrade – Correct version for ” & sProductVersion & ” should be ” & sRefBiosVersion, LogTypeInfo
                    oLogging.CreateEntry “Config-BIOSUpgrade – Upgrading ” & sProductVersion & ” from ” & sBIOSVersion & ” to ” & sRefBiosVersion, LogTypeInfo

                    sExecuteCommand = sDeployDrive & “\BIOSUpgrade\Lenovo\” & sExeToRun & sDeployDrive
                    oLogging.CreateEntry “Config-BIOSUpgrade – Command to execute ” & sExecuteCommand, LogTypeInfo

                    iRetVal = oUtility.RunWithHeartbeat(sExecuteCommand)
                    if (iRetVal = 0) or (iRetVal = 1) or (iRetVal = 3010) then
                        ZTIProcess = Success
                    Else
                        ZTIProcess = Failure
                    End If
                End If
       
        Case “Hewlett-Packard”
            oLogging.CreateEntry “Config-BIOSUpgrade – ” & sMake & ” is selected”, LogTypeInfo
            oLogging.CreateEntry “Config-BIOSUpgrade – …searching for BIOS upgrades”, LogTypeInfo
            Select Case sModel
                Case “HP EliteBook 8540w” : sExeToRun = “HPEliteBook8540w.cmd ” : sRefBiosVersion = “68CVD Ver. F.0A”
                Case Else : sExeToRun = “NA”
            End Select
                If sExeToRun = “NA” Then
                    oLogging.CreateEntry “Config-BIOSUpgrade – No support for ” & sModel, LogTypeInfo
                Elseif sSMBIOSBIOSVersion = sRefBiosVersion Then
                    oLogging.CreateEntry “Config-BIOSUpgrade – No upgrade needed”, LogTypeInfo
                Else
                    oLogging.CreateEntry “Config-BIOSUpgrade – Correct version should be ” & sRefBiosVersion, LogTypeInfo
                    oLogging.CreateEntry “Config-BIOSUpgrade – Upgrading ” & sModel & ” from ” & sSMBIOSBIOSVersion & ” to ” & sRefBiosVersion, LogTypeInfo

                    sExecuteCommand = sDeployDrive & “\BIOSUpgrade\Hewlett-Packard\” & sExeToRun & sDeployDrive
                    oLogging.CreateEntry “Config-BIOSUpgrade – Command to execute ” & sExecuteCommand, LogTypeInfo

                    iRetVal = oUtility.RunWithHeartbeat(sExecuteCommand)
                    if (iRetVal = 0) or (iRetVal = 3010) then
                        ZTIProcess = Success
                    Else
                        ZTIProcess = Failure
                    End If
                End If
        Case Else
            oLogging.CreateEntry “Config-BIOSUpgrade – ” & sMake & ” Hey, that’s a brand I have never herd of, interesting…”, LogTypeInfo
    End Select
    oLogging.CreateEntry “———————————————-“, LogTypeInfo
End Function
</script>
</job>


So, now when we have the script created maybe I should try to explain what it actually is doing, I mean you might want to do some modification to it and then it is kind of nice to know where to poke around, So here is the short story.

  • First we make a bunch of Dim’s and the reason is simple and it is called “Option Explicit”. That is set globally in MDT and that means that it will blow up if you try to use a variable that is NOT declared (you might have seen a Error 500: Variable is undefined in MDT.
  • Next I dump all these variables to the bdd.log file, this is mainly need when you trouble shoot things and when you like to look at log files
  • Next up is, well here is the trick to make Lenovo machines run firmware updates in WinPE. The reason they does not work is because the utility looks at the state of power. They do that for one reason, to verify that the machine are running with the power cord connect to a power source and not running on battery (make sense). The secret source is to run this command:
  • oUtility.RunWithHeartbeat(“drvload \Windows\inf\battery.inf”)
  • The oUtility.RunWithHeartbeat is part of a function that gets loaded when we load up the library that is called ZTIUtlity.VBS which is a part of MDT and here is a tip for you, you should always base your script in MDT on a template that will leverage the use of ZTIUtility.vbs. I also set one condition here and that is to only load the driver when we are running WinPE, there is no point in loading it when we run the full-blown OS, it will be loaded in that case.
  • The rest is kind of easy, what will happen is that we will use the %Make% variable in MDT to see in what section we should continue, then when we we find the correct one we will get the %model% in all cases besides when it is a LENOVO, in that case we will use ProductVersion instead and if we find something that is a match when the compare the RefBios value with the version of the BIOS in the machine, it it is the same we just bail out and we are done, otherwise we will find the command to run. My first attempt of creating this had a small “flaw” and it took a couple of “angry-management seconds) to find out why and how to fix it, and the trick is that I need to run many of these firmware updates utilities on a drive letter, some of the work using UNC, but far from all and this must work in all situations, so I need a drive letter, but I cannot trust on MDT to always use Z:, so by using a built in variable called  DeployDrive to deliver that to me and that is why we will build the command to execute based on a bunch of variables
  • So, what does this means, well. In the scripts folder you will have to create a folder structure called BiosUpgrade and in the folder you then create Subfolders for each and every Vendor you have and those folders you the create one folder for each and every model and in those folders you put the firmware. It also means that you need to update this script whenever you have new versions of vendors, models and new versions of BIOS and firmware (well, I could have spent yet one night more to make it one step more dynamically, but hey I need to sleep sometime)

The Batch file…

Now as you can see in the script I have one batch file for each model,

(Looks like this in the VB)
Case “ThinkPad T410″ : sExeToRun = “ThinkPadT410.cmd ” :

that batch file need a header to work, the header will make sure that you will be “in” the folder where the executable is located, that will not be needed every time, but most likely it will be needed most of the time and that batch file should look like this

%1
CD %0\..\
REM *** For testing only *** DIR > list.txt
REM Run your silent command here that will update the BIOS
REM Note: It MUST be silent and it should NOT restart the machine when it is done

Now, since you are (mots likely) a bit curios you will notice that the first line is a %1 and the reason behind that is kind of simple, %1 is the first parameter after the batch file it self, but hey, where did that variable come from??? Well, take a look at the line of execution, if you look really close you will see that we end that that line with a space in the end and the we use the DeployDrive variable and that will result in one thing. When the batch file runs it will first make sure it sets the working drive to the drive where the firmware updates are located and then we run the really old-school command

CD %0\..\

If %1 is the first parameter after the batch file, what the heck is the %0, well here is the fun thing. It’s the batch file name it self (you can test this by creating a batch file with just one line it it “Echo %0” and you will see that the result will be the name of the batch file name itself, the we just use \..\ which sets the working directory to the same location where the script is located and that is exactly what we need. Problem solved (using the MacGyver method)

The Folder Structure

Here is the folder structure that I have in the Scripts folder. In this folder structure I will store all the “Upgrades” plus the batch file. It should look like this to match the script.

image

So, in the scripts folder you will create Dell, Hewlett-Packard, LENOVO and so on, in the next level you create one folder for each model and that folder you store the upgrades,

Last step

The last thing you need to do is pretty easy. Open up your task sequence and add a Run Command that runs the ZTIBiosUpgrade.wsf. The run command should look like this:

cscript.exe “%SCRIPTROOT%\ZTIBiosUpgrade.wsf”

You can put the Run Command in the first section if you want to, there is were we did put it in the customer solution, something like this.

image

(Hey, if you ever wonder when I have time to write many of my postings it’s right now, somewhere over the Atlantic ocean flying at 10.000 feet or more with the headset filled with old-school rock, the flight attended just went pass me asking for more to drink and yes, she gave me a bunch of coke can’s. Thank you Swiss.)

A short note, this will of course work with servers too, just need to do some small adjustments

/Mike

Posted in Deployment, Windows 7, Windows Server 2008 R2 | Tagged: , , , , , , , | 53 Comments »

Windows Server 2008 R2 Deployment using MDT 2010 – Part II – “Doing the HP Stuff”

Posted by Mikael Nystrom on April 5, 2011

Recently I have done a bunch of “Deploying Windows Server 2008 R2” sessions, one at MMS 2011 on Server Deployment using MDT 2010 and one at Geek Week and at both occasions  I was asked to give the details on how I do deploy HP servers. Now, this is not a complete guide from A-Z, but it should give you something that covers most of the configuration needed and also you should be able to see the “pattern” on how to do this. If you do have some special requests, just send an email and I’ll do one more posting on the subject.

The goal for this post is too see how you could automate installation of drivers, support pack, firmware update on HP BL/DL/ML series of hardware (Yes, I’ll create another post on how to do it on Dell servers later…)

Support Pack

Ok, so lets assume we have a HP BL 465C G5 and we would like to install Windows Server 2008 R2 x64 SP1. We would also like to have the firmware updated and the support pack installed. I mean, that sound reasonable, right? Yes, it can be done, in fact I do this all the time, in fact so often that I hardly can remember how to do it manually anymore. If you would like to play with all the other switches that hpsum.exe can do, look for a file called CLIHELP.txt, it is in the same folder where you unpack the stuff.

Let’s begin with the support pack, current version is 8.60.

  • Download HP PSP 8.60 from: http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?lang=sv&cc=se&prodNameId=3716247&taskId=135&prodTypeId=18964&prodSeriesId=3716246&lang=sv&cc=se
  • Uncheck the “this files is download from internet stuff” on the properties page of the file, otherwise you risk to have that “safety” thing stuck on the files at that might get you to small issues later on.
  • Create a folder for the PSP, call it “INSTALL – HP Support Pack 8.60” and in that folder create a folder called “source”. The Source folder is where we store everything that will be installed, the root folder is for storing scripts that works as wrappers to install the application. This very basic principal applies to EVERY application you are installing using MDT.
  • In the root folder you create Install-HP_PSP.WSF that works as the wrapper and it should look like this:


<job id=”Install-HP_PSP”>
<script language=”VBScript” src=”..\..\Scripts\ZTIUtility.vbs”/>
<script language=”VBScript”>
‘//—————————————————————————-
‘// Solution: INSTALL
‘// Purpose: Install-HP_PSP
‘// Usage: cscript Install-HP_PSP.wsf [/debug:true]
‘// Version: 1.1 – 15 Mar 2011 – Mikael Nystrom
‘// This script is provided “AS IS” with no warranties.
‘//—————————————————————————-
‘// Global constant and variable declarations
‘//—————————————————————————-

Option Explicit

Dim iRetVal

‘//—————————————————————————-
‘// End declarations
‘//—————————————————————————-

‘//—————————————————————————-
‘// Main routine
‘//—————————————————————————-

On Error Resume Next
iRetVal = ZTIProcess
ProcessResults iRetVal
On Error Goto 0

‘//—————————————————————————
‘//
‘// Function: ZTIProcess()
‘//
‘// Input: None
‘//
‘// Return: Success – 0
‘// Failure – non-zero
‘//
‘// Purpose: Perform main ZTI processing
‘//
‘//—————————————————————————
Function ZTIProcess()

    oLogging.CreateEntry “Install-HP_PSP: Starting Install”, LogTypeInfo
    oUtility.RunWithHeartbeat(“source\hpsum.exe /silent /use_snmp”)
    oLogging.CreateEntry “Install-HP_PSP: Finished Install”, LogTypeInfo   
   
End Function

</script>
</job>


As you can see, the active part of the install is “hpsum.exe /silent /use_snmp”. There is a bunch of other settings you can use, but these are the ones I use.

Firmware Packages

We also need the firmware, it is possible to combine it so that patches and firmware installs at the same time, or even possible to let them find new firmware updates using the web, but this is the way I like it, a bit boring but it works…

  • Download HP Firmware ISO from: http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?lang=en&cc=us&prodNameId=1844068&taskId=135&prodTypeId=18964&prodSeriesId=1844067&lang=en&cc=us
  • Uncheck the “this files is download from internet stuff” on the properties page of the file, otherwise you risk to have that “safety” thing stuck on the files at that might get you to small issues later on.
  • Create a folder for the PSP, call it “INSTALL – HP Firmware 9.20” and in that folder create a folder called “source”. The Source folder is where we store everything that will be installed, the root folder is for storing scripts that works as wrappers to install the application.
  • Now, the trick is that when you extract the ZIP file that you download, it contains an ISO image, you need to open that and then extract the content from the ISO and save that in the Source folder
  • In the root folder you create Install-HP_FW.WSF that works as the wrapper and it should look like this:

<job id=”Install-HP_FW”>
<script language=”VBScript” src=”..\..\Scripts\ZTIUtility.vbs”/>
<script language=”VBScript”>
‘//—————————————————————————-
‘// Solution: INSTALL
‘// Purpose: Install-HP_FW
‘// Usage: cscript Install-HP_FW.wsf [/debug:true]
‘// Version: 1.0 – 4 Apr 2011 – Mikael Nystrom
‘// This script is provided “AS IS” with no warranties

‘//—————————————————————————-
‘// Global constant and variable declarations
‘//—————————————————————————-

Option Explicit

Dim iRetVal

‘//—————————————————————————-
‘// End declarations
‘//—————————————————————————-

‘//—————————————————————————-
‘// Main routine
‘//—————————————————————————-

On Error Resume Next
iRetVal = ZTIProcess
ProcessResults iRetVal
On Error Goto 0

‘//—————————————————————————
‘//
‘// Function: ZTIProcess()
‘//
‘// Input: None
‘//
‘// Return: Success – 0
‘// Failure – non-zero
‘//
‘// Purpose: Perform main ZTI processing
‘//
‘//—————————————————————————
Function ZTIProcess()

    oLogging.CreateEntry “Install-HP_Firmware: Starting Install”, LogTypeInfo
    oUtility.RunWithHeartbeat(“Source\hp\swpackages\hpsum.exe /silent”)
    oLogging.CreateEntry “Install-HP_Firmware: Finished Install”, LogTypeInfo   
   
End Function

</script>
</job>


SNMP Configuration

We also need to fix SNMP (in most cases), so we need to install it and if you want SNMP to work correctly for the Support Pack you also need to configure it. And that of course is done by a script.

Create a folder called “CONFIG – SNMP”

In that folder create a file called “CONFIG-SNMP_Services.wsf” that looks like this:


<job id=”CONFIG-SNMP_Services”>
<script language=”VBScript” src=”..\..\Scripts\ZTIUtility.vbs”/>
<script language=”VBScript”>

‘//—————————————————————————-
‘// Solution: Hydration
‘// Purpose: Used to configure SNMP
‘// Usage: cscript CONFIG-SNMP_Services.wsf [/debug:true]
‘// Version: 1.0 – 3 Apr 2011 – Mikael Nystrom
‘//
‘// This script is provided “AS IS” with no warranties, confers no rights and
‘// is not supported at all.
‘//
‘//—————————————————————————-

‘//—————————————————————————-
‘// Global constant and variable declarations
‘//—————————————————————————-

Option Explicit

Dim iRetVal

‘//—————————————————————————-
‘// End declarations
‘//—————————————————————————-

‘//—————————————————————————-
‘// Main routine
‘//—————————————————————————-

On Error Resume Next
iRetVal = ZTIProcess
ProcessResults iRetVal
On Error Goto 0

‘//—————————————————————————
‘//
‘// Function: ZTIProcess()
‘//
‘// Input: None
‘//
‘// Return: Success – 0
‘// Failure – non-zero
‘//
‘// Purpose: Perform main ZTI processing
‘//
‘//—————————————————————————
Function ZTIProcess()

 

    oLogging.CreateEntry “CONFIG-SNMP_Services Adding Community string Public to Registry”, LogTypeInfo   
    oShell.RegWrite “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities\Public”, 8, “REG_DWORD”

    oLogging.CreateEntry “CONFIG-SNMP_Services Stopping SNMP Service”, LogTypeInfo   
    oUtility.RunWithHeartbeat(“NET.exe STOP SNMP /y”)
   
    oLogging.CreateEntry “CONFIG-SNMP_Services Waiting 1000″, LogTypeInfo   
    wScript.Sleep 1000

    oLogging.CreateEntry “CONFIG-SNMP_Services Starting SNMP Service”, LogTypeInfo   
    oUtility.RunWithHeartbeat(“NET.exe START SNMP /y”)

    oLogging.CreateEntry “CONFIG-SNMP_Services Finished SNMP Configuration”, LogTypeInfo   
   
End Function

</script>
</job>


Modifying the Task Sequence

There are many ways of dosing this, you can either do it in the database or customsettings.ini, but in most cases I have found it easier to do this in the task sequence.

You need to create a standard server task sequence with Windows Server 2008 R2 x64 and when you have done that you need to open it up and directly under “State Restore – Tattoo”, you add a new tree structure that looks like this:

image

As you can see I have added a new group called Hardware and under that folder you have HP. You can also see that the condition for running the content of that folder is that “Make” must be HP, same goes for the next step. The group called ProLiant BL 465c G5 has a similar filter, it is only processed when the “Model” is Proliant BL 465c G5. So you just add a folder structure based on make/model. You can get the Make by running “wmic csproduct get name” from the command prompt on the machine and if you need “Make” it is “wmic csproduct get vendor”

Adding the Application and Settings

No, using deployment workbench you browse down to applications and in there I normally create two folders, one is called INSTALL (Contains real applications) and CONFIG (contains only configuration scripts).

  • Create a application with source files, pointing to “CONFIG – SNMP Services” folder, give the application the same name as the folder and set the run command to “cscript.exe CONFIG-SNMP_Services.wsf”

 

  • Create a application with source files, pointing to “INSTALL – HP PSP 8.60” folder give the application the same name as the folder and set the run command to “cscript.exe Install-HP_PSP.WSF”
  • Create a Bundle called “HP Support Pack”
  • Modify the bundle “HP Support Pack” to be dependent of INSTALL – HP PSP 8.60

 

  • Create a application with source files, pointing to “INSTALL – HP Firmware 9.20” folder give the application the same name as the folder and set the run command to “cscript.exe Install-HP_FW.WSF”
  • Create a Bundle called “HP Firmware Update”
  • Modify the bundle “HP Firmware Update” to be dependent of INSTALL – HP Firmware 9.20.

This way, you will only use the bundles whenever you reference these installations and that makes it so much easier if you update the support pack, the you just add a new support pack, flip inside the bundle, test and if it does not work as expected you can keep the old one while you are investigating “why” it fails. Again, there are at least 10 other ways of doing this, I just think it is easy and convenient.

Add tasks to the task sequence

Now it is time to do the last part of this, modifying the task sequence so it will do all the steps for you.

Open the task sequence and add the following tasks under the group for your server (in my case, the BL 465c G5)

  • Install SNMP = Roles and Features with SNMP checked
  • CONFIG – SNMP Services = Install Application – CONFIG – SNMP Services
  • INSTALL – HP Support pack = The HP Support pack Bundle
  • INSTALL – HP Firmware = The Firmware bundle

It should look something like this

image

So, as you can see it is not that hard to do it, should be able to figure out on how to do other similar tasks and for other vendor/models

/mike

Posted in Deployment, Windows Server 2008 R2 | Tagged: , | 18 Comments »

Microsoft iSCSI Software Target 3.3 for Windows Server 2008 R2 available for public download

Posted by Mikael Nystrom on April 4, 2011

YES !!!

Microsoft is releasing the iSCSI Target Server and that means that you now can use a Windows Server 2008 R2 x64 OS as a SAN by adding this download, it is so cool!!!.

The Microsoft iSCSI Software Target 3.3 provides storage (disks) over a TCP/IP network. It turns a computer running Windows Server into a storage device which provides shared block storage. You can use Microsoft iSCSI Software Target 3.3 to perform a variety of storage-related tasks, including the following:

  • Provide shared storage for Hyper-V to enable high availability and live migration
  • Consolidate storage for multiple application servers (i.e. Microsoft SQL Server or Hyper-V)
  • Provide shared storage for applications hosted on a Windows failover cluster
  • Enable diskless computers to boot remotely from a single operating system image using iSCSI

The Microsoft iSCSI Software Target 3.3 is an economical solution suited for a development or test environment and a small, medium, or branch office production environment. It enables storage consolidation and sharing on a Windows Server by implementing the iSCSI (Internet Small Computer Systems Interface) protocol, which supports SCSI-block access to a storage device over a TCP/IP network. For details on how to manage iSCSI targets, see http://technet.microsoft.com/en-us/library/gg232606(WS.10).aspx.

Read more here and get the download

Blog: http://blogs.technet.com/b/josebda/archive/2011/04/04/microsoft-iscsi-software-target-3-3-for-windows-server-2008-r2-available-for-public-download.aspx

TechNet: http://technet.microsoft.com/en-us/library/gg232597.aspx

Download: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=45105d7f-8c6c-4666-a305-c8189062a0d0

Posted in Hyper-V, iSCSI, Windows Server 2008 R2 | Tagged: , , | 1 Comment »

MDT and OU’s, including spaces and odd characters

Posted by Mikael Nystrom on February 22, 2011

I got a question some time ago, it was something like this:

-Hi Mike, just a short question, we can’t get the MachineObjectOU to work since we have a bunch of OU’s that are named using Swedish characters. Do you have any ideas?

And yes, ideas I do have, trust me. So I started playing around and I did discover that MDT does not really like the Unicode format at all, MDT works perfectly fine using ANSI.

I also did some research on Internet and I did discover that there was people asking for this, but no answers. After spending some time in MDT, creating scripts with different levels of success my brain begun to work, A of memory from the past pops up, didn’t Active Directory handle that somehow…and yes, it does. But before we go into that, let’s see how we can put a computer in the correct OU.

Alternative 1:

You can use a property called MachineObjectOU and when in use it could look something like this in customsettings.ini

[Settings]
Priority=MacAddress, Default
Properties=MyCustomProperty

[00:15:1a:1b:1c:1d]
OSDComputername=PC001
MachineObjectOU=OU=ComputersA,OU=Company,DC=viamonstra,DC=com

[Default]
OSinstall=Y

Alternative 2:

If you use the wizard you can use “DomainOUs” in customsettings.ini, that way you will be presented with a list of OU’s to pick from, looks something like this:

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSinstall=Y
DomainOUs1=OU=ComputersA,OU=Company,DC=viamonstra,DC=com
DomainOUs2=OU=ComputersB,OU=Company,DC=viamonstra,DC=com

Alternative 3:

One other option is to use an xml file called “DomainOUList.xml”, you create it in notepad and save it in the scripts folder in MDT and it should look something like this:

<?xml version=”1.0″ encoding=”utf-8″?>
<DomainOUs>
<DomainOU>
OU=ComputersA,OU=Company,DC=viamonstra,DC=com
</DomainOU>
<DomainOU>
OU=ComputersB,OU=Company,DC=viamonstra,DC=com
</DomainOU>
</DomainOUs>

But, what if I have spaces in my OU name?

Easy, it works perfect, just type in the name of the OU including spaces, like this:

DomainOUs1=OU=This OU has Spaces,OU=Company,DC=viamonstra,DC=com

But, what if I have Swedish characters in my OU name, like ÅÄÖ?

Easy, replace the characters according to this: Å=A, Ä=A, Ö=O.

If the OU is named “Vård och Omsorg” in Active Directory it should look like this:

DomainOUs1=OU=Vard och Omsorg,OU=Company,DC=viamonstra,DC=com

I can’t remember what the function in Active Directory is called, but I know it works. You could test this easy, create a OU called “Östra skolan” and the try to create a OU at the same location called “Ostra skolan”. Can’t be done, “object already exist”

/mike

Posted in Deployment, Windows 7, Windows Server 2008 R2 | Tagged: , , | Leave a Comment »

Roadshow in Sweden–2 Weeks of FUN :-)

Posted by Mikael Nystrom on January 30, 2011

It is time to get out on the road again, 2 weeks and that means 8 cities my friends, Göteborg (1/2), Helsingborg(2/2), Jönköping(3/2), Stockholm(4/2), Västerås(15/2), Örebro(16/2), Norrköping(17/2) and Växjö(18/2).

The roadshow is about the new Servers in the Windows Server family, we are going to talk about:

  • Windows Server 2008 R2 Standard
  • Windows Server 2008 R2 Foundation
  • Small Business Server 2011 Standard
  • Small Business Server 2011 Essentials

Go to http://www.microsoft.se/lyftet and look for “Roadshow” and get a spot for the “show”. After the show I will most likely hang around in the hotel bar for a beer, and anyone paying gets frees support of course…

Did I mention that this is totally free, if not it is… Smile

/mike

Posted in RoadShow, Windows Server 2008 R2 | Tagged: , , , | Leave a Comment »

Windows Server deployment using MDT 2010

Posted by Mikael Nystrom on December 21, 2010

Using MDT 2010 for server deployment is one of those things that really make sense, it’s free, it is somewhat easy, pretty fast to get up and it does not require a large infrastructure and has very few dependencies. The last two things makes it a very decent candidate for smart server deployment. Yes, there will be a book on the subject…

No, this time we will take a look at two things  that I use basically all the time:

No:1 – Time

Many times I flash firmware before installing the OS, make sense to me to have the latest version before the server is put in production, now that normally works well but sometimes it just happens that my servers get affected by a “time-warp”, after flashing the server seems that 1980 is the current year, now that is not really an issue but I have had some bad experience around this, first the 60 days of trial is kind of gone, if you deploy domain controllers, well lets not talk about that. There is a very easy fix for this, you just modify the task sequence in the beginning so that the time gets set from the deployment server before the OS is installed:

Pic1

No:2 – The Extra Partition…

When you deploy Windows Server 2008 R2 using MDT it will create an extra partition that has a size of 300Mb in the end of the first disk, that partition is meant to be the partition that stores the boot files if we are going to encrypt the drive using bit locker, now that is very nice… but since many of my servers are virtualized there is no point of that, even worse, since the partition is on the “right” side of the disk I cant just remove it if I need to extend the disk and then extend the partition, it is just something I don’t want to have. There is a variable called DoNotCtreateExtraPartiton that we can use, if we use with with the IsVM variable it is really easy, here is to pictures of how I do it in a task sequence, the first picture is the Properties tab where we set it and the next one is the options tab where we set the condition.

Pic2

Pic3

/mike

Posted in Deployment, Windows Server 2008 R2 | Tagged: , , | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.

Join 4,367 other followers