A project that I recently worked on was using SCCM to upgrade their fleet to Windows 7. The 7402 uses integrated graphics in the 852GM and 852GME chip. The problem here is that this is very old and unsupported by NCR and Intel – so when installing Intel 852GM/852GME/855GM/855GME Series video driver Windows 7 reverts back to Standard VGA adapter after restart. After a day of banging my head against a wall, I came up with a solution for this. The solution is automated and deployable via SCCM. At the moment I cannot reveal the exact process, but for anyone that is experiencing the same problem, contact me and I can possibly point you in the right direction….

I’ve previously blogged about using TightVNC in WinPE. This time I have successfully intergrated DameWare Remote Control 7.5 into WinPE 3.1.

In my case I was using an x86 version of Windows PE 3.1. I am using UNATTEND.XML to install the DameWare process. We cannot use tsconfig.ini because it is called too late in the process and I want the DaweWare executable to run immediately upon network connectivity. WinPEShl.ini cannot be used as SCCM overwrites this file everytime you update the boot image / DP. Startnet.cmd cannot be used as this is not called if WinPEShl.ini exists.

Mount your BOOT.WIM file using something like DISM.exe, in this example I am mounting it to c:\MOUNT.

Download DameWare from the website and install to your workstation. Navigate to “%programfiles%\DameWare Development\DameWare Mini Remote Control 7.5″ and copy *.exe and *.dll to c:\mount\windows\system32, except for DWRCC.exe & DWRCSMSI.exe (if you don’t copy all of these files, later on you will get a prompt to update /repair client).

Create a batch file called DAMEWARE.BAT and copy it to c:\mount\windows\system32. Add the following commands to the DAMEWARE.BAT and then save:

“%SYSTEMROOT%\System32\DWRCS.exe” -install
net user administrator password

The above commands install the DameWare process and then creates a WinPE administrator account with the password that you have specificed.

Create a file called UNATTEND.XML and copy it to c:\mount. Add the following content to the file and then save:

Now unmount your WIM file, making sure you commit. Add it to SCCM or WDS or whatever you are using for deployment services. Once you boot from this you will now be able to connect to the machine via DameWare! Use the password you have specified in the batch file above. I recommend using this in conjunction something like BGInfo so that the IP address is shown on the background.

Related links:

• http://joejoeinc.blogspot.com/2010/05/how-to-enable-remote-control-in-winpe.html
• http://forums.dameware.com/viewtopic.php?f=9&t=469&p=5437&hilit=winpe#p5437
• http://www.deploymentresearch.com/Blog/tabid/62/EntryId/36/Software-Assurance-Pays-Off-Remote-Connection-to-WinPE-during-MDT-SCCM-deployments.aspx
• http://social.technet.microsoft.com/Forums/en-GB/mdt/thread/ec0c33a7-16c7-4758-b90e-5dfbc3ed5ea1
• http://technet.microsoft.com/en-us/library/cc766521(WS.10).aspx

This is an old trick, one that I have been using for many years, but I’ve never documented it. Often when working with SCCM, you will need to test how something will operate when running in the SYSTEM context (as opposed USER context) – scripts, exes, msis, lots of things. I’ve used the trick with PSEXEC, where you just run ‘psexec.exe -i -s cmd.exe’ and you are presented with a command prompt running in the SYSTEM context – from here you can run your test commands. There is a good writeup about it over here – http://verbalprocessor.com/2007/12/05/running-a-cmd-prompt-as-local-system/ if you need any further information.
 
 

I had a need for an accurate timezone and specific date format during Windows PE session when using SCCM OSD.

To change timezone:

At the start of the task sequence, run a command like “reg.exe import AUS_EST.reg”
This is simply an export of HKLM\System\CurrentControlSet\Control\TimeZoneInformation.
In my case, the contents of AUS_EST.reg looked like:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
“Bias”=dword:fffffda8
“StandardName”=”AUS Eastern Standard Time”
“StandardBias”=dword:00000000
“StandardStart”=hex:00,00,04,00,01,00,03,00,00,00,00,00,00,00,00,00
“DaylightName”=”AUS Eastern Daylight Time”
“DaylightBias”=dword:ffffffc4
“DaylightStart”=hex:00,00,0a,00,01,00,02,00,00,00,00,00,00,00,00,00
“ActiveTimeBias”=dword:fffffd6c

To change date format in WinPE:

Mount WIM using DISM
Load hive “mount”\Windows\System32\config\DEFAULT into registry
Navigate to the loaded hive then Control Panel\International
Update the values you need to in here such as sLongDate and sShortDate
Unload hive
Unmount WIM using DISM, ensuring that you use the /commit switch

For more info on editing the registry for a WIM file, see my other post http://blog.danovich.com.au/2010/03/16/edit-the-registry-inside-a-wim-file/
 
 

During a new deployment of a Certificate Services, I needed to increase the validity period of the CA certificate issued from the root (and offline) CA to the issuing CA (online and domain joined). By default this is only valid for 1 year. After unsuccessful hunting around the GUI options, I realised that this is going to be a registry change:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\
Find ValidityPeriod. Set the value one of the following – Days, Weeks, Months or Years.
Find ValidityPeriodUnits and set this to the numeric value that you want.
Then restart the Certificate Services NT service.

I made this change on both the root CA and issuing CA because I wanted to increase the validity period of not just the CA certificate that is issued from the root CA, but also any certificates that are issued from the issuing CA also. Be aware that validity period may also be set in the certificate template and templates supported by Windows 2000 and Windows Server 2003 Standard Edition cannot be modified. Templates supported by Windows Server Enterprise Edition (Version 2 templates) do support modification.

There is a bit more detail here if required – http://support.microsoft.com/kb/254632.

Fresh from my recent trip to TechEd, I learnt about a way to remotely connect to a WinPE session using a new Microsoft tool called Dart. For more info on this tool, see here – http://www.deploymentresearch.com/Blog/tabid/62/EntryId/36/Software-Assurance-Pays-Off-Remote-Connection-to-WinPE-during-MDT-SCCM-deployments.aspx .

This prompted me to think what organisations without Microsoft software assurance (MDOP) can use for remote connection to WinPE. I successfully configured and used TightVNC version 2.0.2 with WinPE 3.0 (x86) in my environment. Take a look here and here for more hints on how to do this. I used the same method to get BGInfo to run at WinPE startup.