There is no need to invent the wheel again as this can be achieved very easy in Microsoft Deployment Toolkit. Start by downloading Microsoft Deployment Toolkit and in the components section make sure to download and install Windows Automated Installation Kit. Start Deployment Workbench and off we go!

Note: This guide applies to everyone regardless if you are deploying Window using SCCM, MDT or any third party deployment solution.

1. In Deployment workbench create a new share for creating the reference image so start by creating a new one and name it like “Reference image build and capture share” or something of your choice.

2. Add the OS install files (repeat for each OS you want to build for) into the operating systems folder. Always include the setup files so never install just a WIM file at this stage.

3. Create a task sequence based on the Standard client task sequence (repeat for each OS you want to build image for).

4. For each task sequence edit the task sequence to enable the existing but disabled “Windows Update” step(s).

5. Edit the rules of the share by right clicking it and choosing Properties. The rules (customsettings.ini) should look like below. Replace the variables BackupShare and BackupDir with whatever the share name and directory to store the images are.

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipAppsOnUpgrade=YES
SkipCapture=YES
DoCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipUserData=YES
SkipTimeZone=YES
SkipFinalSummary=YES
SkipSummary=YES
SkipLocaleSelection=YES
SkipDomainMembership=YES
SkipComputerName=YES
SkipBitlocker=YES
SkipApplications=YES
ComputerBackupLocation=NETWORK
BackupShare=\\server\share
BackupDir=Captures

6. Modify the bootstrap.ini to look like the below information. Replace the variables according to what applies to your configuration.

[Settings]
Priority=Default

[Default]
SkipBDDWelcome=YES
DeployRoot=\\server\share
UserDomain=CONTOSO.COM
UserID=username
UserPassword=password

7. Now add to the Rules (customsettings.ini) a section named like below. This sets that the Windows Update step will point to your WSUS server, where you are in control of everything that is released by Microsoft and thereby staying 100% in control of what is in your image.

WSUSServer=http://nameofwsusserver

8. To make sure that you get a separate name for each operating system you are building a reference image for edit each task sequence to contain a Task Sequence Variable named for instance:

BackupFile=Windows7Enterprisex64.wim

9. Update the deployment share to get boot ISO which you use to boot your virtual machine and start the build process.

Remember to always build the reference image on a virtual machine to avoid potential problems related to hardware.

You could also add the Office as an application in the Deployment Workbench and to all task sequences that require it to make sure that you have a rapid deployment image ready to go.

Done! Happy deploying!

Note: There is information on how to do this in official MS documents for DaRT 7.0 but you have to do a lot of reading between the lines so I wanted to take the moment to do a complete documentation on how to accomplish this.

Background on WinRE and local admins

Some basic information about WinRE is that whenever you start WinRE (and that includes DaRT 7.0) when it is located on the machines disk it will always ask you to supply a local admin account information. This is not the case if you boot WinRE or DaRT from USB, DVD, CD or via PXE boot, then you do NOT have to enter a local admin account to gain access to the system. Potential security issue here I might add.

Step by step solution

The dilemma with DaRT and remote connections is that we cannot in most cases let the users know the password of our local administrator account so what we can do is to start the remote connection as soon as possible when DaRT boots. So here is what you need to do to achieve this:

1. Go through the DaRT Recovery Image wizard and create your DaRT.iso. Then extract this ISO file and copy boot.wim which can be found in the sources folder to C:\DaRT and rename it to winre.wim.

2. Start a cmd.exe with administrator privileges.

3. Create a folder called C:\DaRTmount

4. Run the following command (on one line and with no space between “mount-” and “wim”:

dism /mount-wim /wimfile:C:\DaRT\winre.wim /index:1 /mountdir:C:\DaRTmount

5. From the same command prompt, type “notepad” to start Notepad and then browse to C:\DaRTmount\Windows\System32 and open winpeshl.ini. Make sure that this is entered into the winpeshl.ini and then save the file:

[LaunchApps]
"%windir%\system32\netstart.exe -network -remount"
"cmd /C start %windir%\system32\RemoteRecovery.exe -nomessage"
"%windir%\system32\WaitForConnection.exe"
"%SYSTEMDRIVE%\sources\recovery\recenv.exe"

6. When the file is saved make sure that you have closed notepad and also all instances of Windows Explorer (yes, the following command might fail if you have Explorer windows open) run the following command:

dism /unmount-wim /mountdir:C:\DaRTmount /commit

7. After the image has been saved you need to replace the existing Windows recovery environment with your customized DaRT installation.

8. Start by making sure that you show hidden and operating system files (via Windows Explorer – Organize – Folder and search options – View).

9. Go to C:\Recovery (if you get “access denied”) you need to modify the access control list, add your account or everyone full control to this folder.

10. Now scroll down the folder structure until you reach where winre.wim is located. Now copy your modified winre.wim from C:\DaRT to this location. Remember to set the ACLs back on the recovery folder when you are finished, that is if you modified them.

11. Test by booting the machine and press F8 just before Windows starts loading and you will get “Repair your computer” option. Choose that and see how the Remote Connection is started along with the prompt for local administrator password, giving your users a chance to let you connect and then giving the IT staff enter the password.

12. Done!

The problem was that the System Locale was not set properly for my Windows 7 box. Fix was to set it under Region and Language – Administrative tab and there set the system locale and restart the machine. After that the SQL Server installation went fine!

Deployment Roadshow vNext will take place in Sweden’s four largest cities and it will be presented by myself and colleague Johan Arwidmark from Knowledge Factory, Wally Mead the SCCM guru from Microsoft Corp and Mikael Nyström from Truesec. More info about the event at http://www.deploymentevents.se.

The Windows 8 loadfest will take place in early December in Stockholm and it hosted by me, Johan Arwidmark, Lars Gustavsson and Tim Nilamaa. More info about the event at http://www.deploywindows8.se.

But anyway thanks to a great builtin PowerShell cmdlet in Windows 7 I could get the job done in seconds. Keep in mind :)

Add-Computer -DomainName contoso.com -Credential contoso.com\joinDomainAccount -OUPath "OU=Company,DC=contoso,DC=com"

Reference: Microsoft TechNet

You can get all the same features if you are using Windows Server 2003 domain controllers and that is also regardless of which forest or domain functional levels you are running with. The most common misconceptions are:

• Group Policy Preferences. Work very well in a 2003 domain. However you need to manage the group policies from a Windows 7 or Windows Server 2008 R2 machine using Group Policy Management Console found in the Remote Server Administration Tools.
• BitLocker. To store recovery keys in AD you need to extend the schema. If you have a domain controller that is running Windows Server 2008 or later you have what it takes, if you are running Windows Server 2003 on your domain controllers you simply extend the schema.

I must add that you get stronger encryption for Kerberos by using Windows Server 2008 domain functional level though but the bottom line is that the functionality of the Windows 7 client is the same regardless of forest or domain functional levels.

With this tool you basically open a system file, for instance a DLL or an OCX file, and it will list its dependencies to other files on the system. This can be good for finding what is causing registration of for instance DLL or OCX files to fail on Windows 7 while it works fine on Windows XP. There can be runtimes missing.

The problem in this case was that whenever they started editing a group policy they got tens and tens of warning about various admx files along with for example resource errors. I looked into PolicyDefinitions folder in the SYSVOL share and immediately noticed that there was admx and adml files missing and that there were mismatch between the version of the admx and adml files.

I took a Windows 7 with SP1 client and added/replaced all admx files from there. After that I took the en-us folder and replaced what was in the SYSVOL folder with that one, followed by doing the same for the sv-se, i.e. the Swedish language files. While at it I installed IE9 and put in the inetres.admx and respective adml files for each language to have the capabilities of editing Internet Explorer 9 policies as that is to be included in the Windows 7 image. Voila!

So the bottom line is; keep the central store consistent and make sure that when you create the store that you populate it with admx and adml files from the latest client OS with service pack when managing Windows 7, and that you do make sure that you have the same version of all admx and adml files or else you will get errors due to mismatching files.

The trick is that the GUI does not provide a way to view these applications so you have to turn to doing a SQL query using for instance the SQL Management Studio Express tools. Use the SQL Query below to get information on any none 32- or 64-bit executable. The query (thanks to Chris Jackson) will return for instance WOW (Windows on Windows) or DOS applications and that will/might indicate a 16-bit app which you should prioritize to test and handle as necessary.

USE ACTDATABASE
GO

SELECT DISTINCT Applications.appName, Static_App_Properties.fileName, fileModuleType

FROM Static_App_Properties
INNER JOIN Application_Instance_Files
ON Static_App_Properties.identity_hash = Application_Instance_Files.filePropertyID
INNER JOIN Applications
ON Application_Instance_Files.appID = Applications.identity_hash

WHERE fileModuleType<>'32BIT' AND fileModuleType<>'64BIT' AND propertyType='File'

ORDER BY appName
GO

Happy hunting for 16-bit applications! :)

The cause of this is UAC and the fact that you have multiple security tokens and that the mapped network drives are linked to the standard user token and not the administrator token. The solution is to enable “Linked Connections”, see the KB article 937624 for more information on how to set this value.

Also read the case of some other mysterious problems or behaviors when UAC is en effect.