Dell starting to transition to advanced format 3.5" drives

Due to the flooding in Thailand, Dell have a announced they are to transition all their desktop systems to Advanced Format hard drives (see Dell article number 408172).

This will probably cause issues with your captured OSD images. For Windows 7 deployments, Microsoft have issued a hotfix (here), but this has been included in Service Pack 1. Windows XP looks like it'll be a bit more complex to get working with the new drives. I'll be blogging more about this once we get our hands on the samples from Dell.

In the meantime, these drives are being phased in, and Dell warn that "multi-unit shipments may include both Advanced Format and conventional (512b) drives."

Deploying the Novell client as part of an OSD Task Sequence

After posting the Novell client GINA fix I remembered how difficult it was to get the Novell client to install as part of a Task Sequence. After trying many different approaches to get the setup to run as an SCCM program, the trick (and it is a trick) is to use the Run Command Line step instead of creating a program.

For some reason, the client install works fine when run like this. Use the same command line as an SCCM program, and it fails. An interesting side effect of running as a Run Command Line step is that you see the install dialog boxes that are normally hidden.

Of course, you still need to make sure OSD sets the correct GINA at the end of the task sequence - I've provided a tiny script to do this job here.

It's also worth noting that this has been tested on a legacy version of the Novell client (as you can see from the picture!). Later versions of the client may not have this issue.

Fixing the Novell client GINA in an OSD Task Sequence

I wrote this bit of code to force XP to display the correct GINA in a Novell environment when you deploy your build with OSD. It's a simple bit of code implementing this advice from the OSD team on how to get SCCM to swap out the GINA at the end of the build.

' Fix novell gina for OSD
'
' v1.0 09/Feb/2009
'
  on error resume next

  set oShell = WScript.CreateObject ("Wscript.Shell")

' From http://blogs.technet.com/inside_osd/archive/2008/06/06/installing-a-custom-gina.aspx

  
  RegPath = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\"

  oshell.RegWrite Regpath & "GinaDLL", "OSDGINA.DLL", "REG_SZ"
  oshell.RegWrite Regpath & "OSDOldGinaDLL", "NWGINA.DLL", "REG_SZ"

  WScript.Quit

Downloading and installing the SCCM 2012 prerequisites

There are a number of prerequisites to install on your server before running the SCCM 2012 installer. Even once the SCCM installer is running, it wants to download some more prerequisites. If you are installing onto a non-network connected machine for testing purposes, you'll need to grab these files by running the installer on some other network connected machine beforehand. I ran this on my Windows 7 x64 workstation, but any modern 64-bit Microsoft OS should do.

From a CMD prompt-

1. Create a folder for the downloaded files (eg mkdir c:\sccm2012prereq)
2. Navigate to smssetup\bin\x64 in the SCCM 2012 source directory
3. Run setupDL.exe c:\sccm2012prereq

You will also need .net Framework version 4.0. This is downloaded as part of the prerequisite step so you can install it on your server from the sccm2012prereq folder. There are two installs, you need to use the dotNetFx40_Full_x86_x64.exe, not the client version as noted in the release notes. Surprisingly the SCCM 2012 installer doesn't automatically install this.

Before you can install SCCM 2012, you'll also need to install SQL Server (I'll cover this in a later post), and some roles and features for Server 2008. The roles and features can be easily installed with the following commands-

servermanagercmd -install web-server
servermanagercmd -install web-mgmt-compat
servermanagercmd -install rdc
servermanagercmd -install bits

Top 10 reasons to avoid Windows 7 32-bit

When considering a Windows 7 deployment you'll have the additional headache of whether to go 32-bit only, 64-bit only or a mixture of both. People in your organisation will have a requirement for 64-bit Windows for any number of reasons, such as large data set processing, or just to use all the RAM in the machine. With most systems shipping with at least 3GB of RAM these days, you really need a strategy on 64-bit Windows, but what should you do?

You should go 64-bit only! And this is why.

1. You'll have one less driver set to maintain
   
   If you are the person in charge of OSD then this should a concern. You really don't want to be maintaining extra sets of drivers for your machines when you don't have to.
   
   Windows 7 64-bit can't use 32-bit drivers, and the 64-bit drivers have to be signed. If you already use OSD for XP, you may end up with three driver sets for each type of hardware you have.
   
   
2. It's easier for the helpdesk
   
   User- "Hi, I've got a problem with my Windows. I think it's Windows 7."
   Desk- "Is it Windows 7 64-bit or 32-bit?"
   User- "Uhhhhh......"
   
   
3. It's easier for your technicians
   
   At the moment you probably only have Windows XP. Your techs can roll out some new machines without thinking. If you add Windows 7 x86 you'll suddenly give them 3 choices-
   
   1. Windows XP
   2. Windows 7 x86
   3. Windows 7 x64
   
   Why would they choose one OS build over another? What software/hardware requires a certain build?
   
   Wouldn't it be easier if they just had-
   
   1. Windows XP for legacy hardware/software
   2. Windows 7 (x64) for everything else
   
   
4. It's easier for you
   
   Let's say you want to disable Adobe Updater on all your Windows 7 machines. You roll out a registry key that contains the following information
   
[HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Updater]
"Enterprise"=dword:00000001

   You then realise that, although your 64-bit machines have the key added, it didn't take effect. This is because you had to deploy this instead
   
   [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Adobe\Updater]
"Enterprise"=dword:00000001

   There's similar confusion to be had with %PROGRAMFILES%. This will resolve to C:\Program Files\ on both 32-bit and 64-bit machines. But some (not all) 32-bit apps install to C:\Program Files (x86)\ on a 64-bit machine instead.
   
   The 32-bit / 64-bit differences are confusing. Making your Windows 7 rollout 64-bit only can help.
   
   
5. Your users don't care
   
   Windows 7 looks and feels exactly the same to your end users whether it's the x86 or x64 version. If you can mitigate the potential hardware and software issues your users will face, give them the 64-bit version.
   
   
6. You have a perfectly good 32-bit operating system at the moment
   
   Windows XP is still perfectly fine for most environments. You understand it, and probably have a rock-solid image. Why introduce another 32-bit OS and a 64-bit OS at the same time? XP can be your 32-bit OS and Windows 7 can be your 64-bit OS. With MED-V you can even run both side by side.
   
   
7. You want to get rid of all those 16-bit apps
   
   Yes, you'll have issues with some apps when moving to Windows 7, so why not add to those problems by breaking all your 16-bit apps too? You should probably be looking at things the other way round - why is your business causing itself problems by running 16-bit apps?
   
   Moving to Windows 7 x64 can be a driving force to get the majority of these ancient apps off your network.
   
   Some of these apps are not mission critical. Get rid of them! When we were in the process of moving to Windows 7 x64 I found some apps that required Video For Windows 1.1 - we managed to get agreement to move away from stuff like this!
   
   
   
   For the mission critical apps - are they still supported? If not, why not? Are management aware of the risk to your business of continuing with these apps?
   
   There will probably be 16-bit apps you still need to run. If these can run in a sandbox, with no need for networking or printing you could use DosBox in conjunction with Windows 3.1. (If you have Software Assurance you should be able to use your downgrade rights to run Windows 3.1 in this way, but check with your Microsoft licensing person).
   
   For mission critical 16-bit apps that require networking look at MED-V. This MDOP component allows you to deploy and manage an XP virtual machine to your Windows 7 desktops.
   
   If you don't have 16-bit apps, you shouldn't have many problems moving to 64-bit Windows. If you do, consider this: Microsoft introduced 32-bit Windows in 1993 - the same year both Jurassic Park and Groundhog Day were released. You've probably got people from high school joining your organisation who are younger than those apps!
   
   (64-bit Windows drops support for OS/2 and POSIX apps too. The mitigation strategies for 16-bit apps should apply here too.)
   
   
8. You want to use more than 4GB of RAM
   
   64-bit Windows 7 can use up to 192GB of RAM. 32-bit Windows is stuck at 4GB of RAM, and even then, each process is only allocated 2GB of virtual memory. You'll start to see machines come with 4GB of RAM by default in the next 18 months.
   
   If this is not an issue for you now, it will be soon.
   
   
9. Kernel mode protection
   
   Windows 7 64-bit includes PatchGuard, a technology that prevents third party software from patching the kernel. (See Wikipedia for a good overview of benefits and limitations of this).
   
   PatchGuard will prevent 32-bit filesystem filters (such as some antivirus software), 32-bit network and video adapter drivers and 32-bit kernel mode printer drivers from installing. This is generally a good thing, as a poorly written kernel mode driver can cause the OS to bluescreen.
   
   
10. The majority of your machines probably support 64-bit Windows already.
    
    A common misconception is that moving to 64-bit Windows will involve replacing your entire desktop estate. It's hard to argue against this unless you have statistics. Try running the following report
    
SELECT
CASE V_GS_PROCESSOR.Is64Bit0
WHEN 0 THEN '32 bit'
WHEN 1 THEN '64 bit'
END AS [CPU Type],
COUNT(*) AS [Count]
FROM
V_GS_PROCESSOR
GROUP BY
V_GS_PROCESSOR.Is64Bit0

    
    Armed with this information you can make a more informed decision. Any PC bought in the last 3 years or so should be 64-bit capable. You may need to add more RAM, and check the graphics hardware has 64-bit drivers, but I'm willing to bet the majority of your machines are 64-bit.
    
    

Updating FCS and FEP2010 without WSUS

Both FCS and FEP2010 can get updates direct from Microsoft, but their behaviour is different enough to cause confusion.

For an FCS client to update from Microsoft you need to opt the machine into Microsoft Update. Just turning Windows Update on is not enough. Unfortunately FCS doesn't give you any information that anything is wrong - it just reports that there are no updates available. Once you've opted in to Microsoft Update everything is fine.

A FEP2010 client can update from Microsoft without you needing to opt the machine into Microsoft Update.

You can prove this to yourself by creating two vbscripts as supplied below, optinMU.vbs and optoutMU.vbs. Using the scripts to opt in and out of Microsoft Update you can see for yourself the behaviour of FCS and FEP2010. If your machine is configured for WSUS, you can set it to use Windows Update by deleting the registry key HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and restarting the Automatic Updates service. While testing you can install the Forefront Client Security client in standalone mode by running CLIENTSETUP.EXE /NOMOM

So, to summarise-

FCS - needs opt in to MU
FEP2010 - no requirement for MU

optinMU.vbs

'from http://msdn.microsoft.com/en-us/library/aa826676(v=vs.85).aspx
Set ServiceManager = CreateObject("Microsoft.Update.ServiceManager")
ServiceManager.ClientApplicationID = "My App"

'add the Microsoft Update Service, GUID
Set NewUpdateService = ServiceManager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"")

optoutMU.vbs

Set ServiceManager = CreateObject("Microsoft.Update.ServiceManager")
ServiceManager.ClientApplicationID = "My App"

ServiceManager.RemoveService("7971f918-a847-4430-9279-4a52d1efe18d")

Making MSI installs behave in OSD

Almost every MSI install package I create these days has the same install parameters.

msiexec /i installer.msi TRANSFORMS="transform.MST" /qb- /l*v %temp%\SCCM_Appname.log ALLUSERS=1

I used to just copy the install parameters from other people, without learning why they'd chosen them. Some MSI install parameters are not appropriate for use within SCCM, but which ones?

Choosing the right parameters can make your OS and software deployments more robust and can make troubleshooting a lot easier.

The full list of msi parameters on Windows XP can be found at support.microsoft.com/kb/314881.

Let's break down this common install string into it's component parts.

• msiexec /i installer.msi
  
  This should be very familiar to anyone maintaining a Windows environment. The /i tells msiexec to install (or sometimes reconfigure) the package installer.msi.
  
  
• TRANSFORMS="transform.MST"
  
  This tells msiexec to apply the transform file transform.MST. Again, this should be pretty familiar.
  
  
• /qb-
  
  There are a number of ways to install an MSI silently, and some are more silent than others! I would argue that any 'silent' install that displays a modal dialog box at the end is not really a silent install and this rules out /qr, /qf, /qn+, and /qb+.
  
  There is no mention of whether /q, /qb, and /qn display modal dialog boxes, but the fact that there is an explicit /qb- which has "no modal dialog boxes" (my emphasis) suggests that they might.
  
  During package deployment we generally don't want the install to prompt the user for any input at all, and /qb- is our only choice here.
  
  
• /l*v %temp%\SCCM_Appname.log
  
  The /l parameter tells msiexec to log actions to a file. You can specify a number of things to log, non-fatal warnings, status messages and so on. When you're troubleshooting you probably want everything logged, so we use /l*, the * being the wildcard parameter. The v ensures the logging is verbose.
  
  The other part of this parameter specifies the filename for the logfile. I put my logfiles in the %temp% folder since I know that it exists, and I prefix the name of each logfile with SCCM_ so that it's easier to find them.
  
  If you're having to troubleshoot an MSI deployment, you'll want to know that the %temp% folder is actually the %windir%\temp folder.
  
  
• ALLUSERS=1
  
  When SCCM installs a piece of software the install normally runs under the LocalSystem account. This can cause problems with poorly created MSI files as described in the following support article-
  support.microsoft.com/kb/916903
  
  The ALLUSERS property value must be defined if Windows Installer is trying to install as a user who differs from the locally logged-on user.
  
  The article suggests using ALLUSERS=2, but other MSDN articles suggest otherwise. This article states that-
  
  An ALLUSERS property value of 1 specifies the per-machine installation context.
  
  -which seems like the right option for SCCM 2007. SCCM 2012 might cause a rethink!
  

Oh, the irony

MMS 2011 Day 3

The dodgy wifi at the Mandalay Bay finally conspired against me and I didn't get a chance to post this entry until today - a full week later. I'll probably type up the other notes as separate blog postings.

Keynote 2 - You! Empowered to Embrace Consumerization

This keynote is available to watch here.

As suspected, SCCM 2012 will be able to do lightweight management of iPad, iPhone, Android and Symbian devices through ActiveSync.

A new feature of SCCM 2012 is Intelligent Application Delivery. This can autodetermine if you're on a corporate machine, an untrusted machine, your primary work machine and so on. It can determine rules based on hardware or software features and then deploy the same Application in different ways based on these rules.

Forefront Endpoint Protection 2010 is now part of the core CAL not just the Enterprise CAL. SCCM 2012 integration now reports on the top users that get viruses, not just the top workstations.

As reported elsewhere client settings can now be set at the collection level, so you don't need a new site just to have different Software Update settings for different machines. You can, however, set default client settings for the entire site and let other admins override them at the collection level. Editing of the sms_def.mof file shouldn't be necessary as you'll be able to enable custom hardware inventory through the client settings.

Windows Intune, a cloud based management service, was launched at the keynote. This looks like a potentially revolutionary way to manage desktop PCs in small to medium businesses.

MMS 2011 Day 2

Day 2 - the first real day of the conference, and the day of the myitforum party!

Keynote 1 - You. Empowered by the Cloud

Surprisingly early start to day 2 with a Keynote at 8.30am. There were two keynotes at MMS 2011, the first focusing on cloud computing, the second on the consumerisation of IT.

First up was the announcement that Opalis has been renamed as System Center Orchestrator. Another new addition to the System Center family is System Center Advisor. This product, formerly codenamed Atlanta, allows you to track config changes on your systems, and compare them with best practices.  The beta is available today.

A key theme in the keynote was separating the apps, data, and OS on servers to provide increased manageability and reliability. Server app-v is a key component here, which can also help reduce the number of OS images you have for your servers. To help with building and managing these private clouds, Microsoft released the beta of Virtual Machine Manager 2012 this morning.

We were given a quick demo of Avicode for client experience monitoring. The most impressive part of the demo was drilling down into exactly what part of a stored procedure is causing slowdowns. 

Tomorrows keynote- the consumerisation of IT. On the slide deck they had a picture of an iPhone- does this mean we'll be managing idevices through sccm soon?

You can watch the first keynote here.

BA01 Configuration Manager State of the Union

After the keynote, comes the 'real' keynote for SCCM. The biggest announcement came at the end!

As usual, lots of top ten lists. Interestingly the User state migration hotfix is the 2nd most applied behind the r3 power management hotfix. I'll be blogging about this particular patch at a later date, it's a pain to apply and affects OSD builds even when you're not using USMT.

As mentioned in the keynote Opalis is now Orchestrator. Out fall 2011 with built in support for sccm 2012. Built in actions like add computer to collection are supported. 

Adobe Reader X has had support for ConfigMgr since November 2010 for updates through SCUP. 

Sccm 2012 beta 2 will be RTW any day now. There's new exclude/include rules for collections!

They provided a great demo of role based administration. Thankfully you can now scope users to collection, and hide features and collections a user doesn't have access to. And at last you can run two instances of the console at once with different credentials. 

2012 has integrated global search across the entire product. They gave the example of searching for Flash. This search returned applications, deployments and software updates. You can drill down and see the context (eg properties of package) direct in the search dialog.

Supercedence is another new feature in SCCM 2012. This allows you to set rules based on versions of a product so that if you install version 9.2 of a product it will first detect and uninstall version 9.1. This also provides a graphical view of the supercedence of your apps. 

SCCM 2012 also provides a graphical view of your site hierarchy. You can enter geographical locations and view a bing map with the location of all your sites. 

An important point for those thinking of evaluating SCCM 2012 that are deploying/have deployed FEP - you'll need to wait for a compatible version of FEP. 

They announced PCM (Package Conversion Manager) to ease the transition to the new application model. This tool analyzes and checks whether classic software packages can be converted to the new app model, and if so, can convert them for you. It has a cool dashboard which gives pie and bar charts for readiness and conversion status.

One potential point of confusion with the new application model that they cleared up - legacy software distribution is still there. You can continue to use the classic way of deploying apps if you want to.

The SCCM 2012 SDK has been updated with powershell cmdlets such as new-collection, get-package. 

Server Configuration Packs look interesting. These are packs of DCM settings built and converted from the Microsoft Best Practices Analyzers. DCM is becoming much more important in SCCM, and has been rebranded as Settings Management for the 2012 release of the product. This now includes settings enforcement to remediate configuration drift. 

They quickly mentioned the P2V Migration Toolkit, which will assist with virtualizing SCCM site systems. Yesterday's BA17 Virtualizing Configuration Manager went into much more depth about this tool.

The last announcement was the headline grabber. SCCM 2012 will support Linux/unix servers. They are planning to offer support for various versions of Red Hat, SuSE, Solaris, HP-UX and AIX. These appear to be the same supported platforms as OpsMgr. The client will offer a subset of current Windows ConfigMgr functionality, and will be available some months after SCCM 2012 RTMs. They revealed a previously hidden talk on Wednesday - BA16 Configuration Manager 2012: Cross Platform Management.

Finally, they will be uploading howto videos for SCCM 2012 on Connect.

BA03 Configuration Manager 2012: Technical Overview

The main change in SCCM 2012 seems to be the Application model. In SCCM 2012 you will be managing applications, not scripts. By managing the Application you get a host of nice new features - automatic revision management and supercedence. As mentioned above, supercedence can enforce the uninstall of a previous version before installing the new version. The Application model also allows a choice of deployment options based on the device the user is sitting at - so, for example, a full install on their primary PC, but a streamed app on any other PC.

The PXE Service Point role has been bundled into the Distribution Point role.

Client health has been greatly improved in SCCM 2012 - a new program ccmeval.exe runs on the client itself and can check and remediate problems with the client.

There's lightweight device management based on Exchange ActiveSync - this will provide limited inventory and tasks that can be run on mobile devices that connect to your Exchange server via ActiveSync.

They've improved the Settings Management (DCM) interface, and you can now browse for Registry keys to check/remediate!

MMS 2011

Day 1 of MMS

According to Brad Anderson Wednesday was day 2 of the conference, so I'm guessing this was day 0.

I went to a couple of nice talks-

BA17 Virtualizing Configuration Manager - What you need to know and how to get there

This was a pretty technical talk which went into a lot of detail about the hardware considerations when looking at virtualizing SCCM 2007.
After covering the hardware, the speaker went into detail about the different ways you could virtualize SCCM. Firstly, you could create a new site in a VM and migrate your existing site to the VM instance of SCCM. Or, you could just run a P2V tool (this is what we did). Looking at my notes, the only thing if importance I've written down is 'don't cluster your MP'.

BA37 Buried Inventory Treasure

A Sherry Kissinger talk, this was full of nuggets of information. I believe Sherry is putting a number of the reports from the demos on her blog. Some of the coolest bits involved DCM. It was a revelation to see SCCM 2007 DCM not just read values, but also set them via scripts.

Another cool demo was Mark Cochrane's RegKeytoMof- a nice tool to autogenerate the code to insert into SMS_def.mof for custom inventory. She's blogged about the new version here.

Hands on lab- Microsoft Bitlocker Administration and Monitoring

Nice solution to the Bitlocker key recovery issue if you're licensed for mdop. This tool backs up enterprise bitlocker keys to a SQL database. A web based portal then allows helpdesk agents recover keys without the need for a domain admin to go near active directory users and computers.

I'm about 2 days behind in my MMS updates, but I'll just blame that on the awful in-room wifi at the Mandalay Bay.

Migrating from Sophos to Forefront Endpoint Protection

One of the great things about deploying FEP 2010 is that it eases the pain of migrating away from your existing antimalware solution. According to the documentation it can detect and remove the following products

• Symantec Endpoint Protection version 11
  
• Symantec Corporate Edition version 10
  
• McAfee VirusScan Enterprise version 8.5 and version 8.7
  
• Trend Micro OfficeScan version 8.0 and version 10.0
  
• Forefront Client Security version 1 including the Operations Manager agent
  

But what if you use Sophos Endpoint Protection?

Sadly, if you're like me you'll have to work it out yourself. Sophos used to provide a script that could uninstall old versions of the client software, however I seem to recall it wasn't officially supported.

The problem with Sophos is that you have two components to remove- the update agent and the antimalware engine.

Both components are installed by MSI packages which are cached in the AutoUpdate folder. So, to perform the uninstall of Sophos you can create a cmd file in your FEP deployment folder with the following lines

msiexec /x "%programfiles%\Sophos\AutoUpdate\Cache\savxp\Sophos Anti-Virus.msi" /qn /quiet /norestart

msiexec /x "%programfiles%\Sophos\AutoUpdate\Cache\sau\Sophos AutoUpdate.msi" /qn /quiet /norestart

FEPInstall.exe /s /q

If you're planning an enterprise deployment you'll probably want to add more error checking in your script, but this should help you get started.

The cache folder can be useful if you still need to deploy Sophos as part of your transition. Create a new package that contains the sau folder from the Cache folder. Create a program with the following command line.

msiexec /i "sophos autoupdate.msi" BOOTSTRAP=NOUPDATE RMSACTION=0 REBOOT=ReallySuppress /qb

This will install the AutoUpdate agent on its own. Once installed, the agent will install the latest version of the antimalware agent from the Central Install Directory.

A final point that applies to both Sophos and Forefront endpoint protection - don't put your antimalware software in your image. Install it as a post-deployment step in your task sequence. This gives you the option to migrate between antimalware packages without the need to recreate your images.

Troubleshooting PXE in SCCM OSD Part 3

Troubleshooting PXE in SCCM OSD Part 1
Troubleshooting PXE in SCCM OSD Part 2 Troubleshooting the TFTP Service
Now that the PXE process is working correctly, we can look at troubleshooting errors surrounding abortpxe.com. If you get this error message then you at least have a working PXE environment, even if SCCM doesn't think it should offer a Task Sequence to the machine. Here are some reasons you'll get this error.

• The machine has not been registered in a build collection
  
  The simplest of all reasons why you get this error. Does the machine have a Task Sequence advertised to it? If not, create a collection, advertise a Task Sequence to that collection and add your machine to the collection. Check smspxe.log, you should see an error such as
  
  ProcessDatabaseReply: No Advertisement found in Db for device 05/03/2011 08:51:36 10368 (0x2880)

  
• The machine has been recently registered in a build collection, but the server takes some time (up to an hour) to process this information
  
  This can be commonly seen when a technician PXE boots the machine to write down the MAC address. If you then create a new computer object based on the MAC address, you need to wait an hour before the WDS service will lookup the database again. You can see this happening in the smspxe.log with an entry such as
  
  MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=00000000-0000-0000-0000-000000000000 > Device not found in the database. 07/03/2011 15:18:46 8552 (0x2168)
  
  This is fixed by this hotfix or SP2 for SCCM. The patch alone won't fix this behavior, you also need to configure a registry setting. If it doesn't already exist, create a REG_DWORD value at
  HKLM\SOFTWARE\Microsoft\SMS\PXE\CacheExpire
  
  ...or on a 64-bit server at...
  
  HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\PXE\CacheExpire
  
  Set the value of CacheExpire to the value you want in seconds - a value of 600 would be a timeout of 10 minutes. On a SP2 SCCM site, setting the value to be 0 will actually set the timeout to 3600 seconds (back to the 1 hour timeout).
  
  If you are unable to apply the hotfix or SP2, stopping and restarting the WDS service can flush out the cache.
  
  
• The SMBIOS guid of the machine is not unique
  
  This can be seen if you have older hardware, or if you've had an engineer swap out some motherboards and not flashed the BIOS correctly.
  
  If you want to find out which machines have duplicate SMBIOS guids then you can run this report-
  
SELECT SMBIOS_GUID0, COUNT(SMBIOS_GUID0) AS Count
FROM v_R_System
GROUP BY SMBIOS_GUID0, Active0, Client0, Obsolete0
HAVING (Active0 = 1) AND (Client0 = 1) AND (Obsolete0 = 0) AND (COUNT(SMBIOS_GUID0) > 1)

  You can then use the following report to pull out the names of the machines with duplicate SMBIOS guids-
  
SELECT SMBIOS_GUID0, Name0
FROM v_R_System
WHERE SMBIOS_GUID0= '00000000-0000-0000-0000-000000000000'

  -where 00000000-0000-0000-0000-000000000000 is the GUID that you identified in the previous report.
  
  The only way to solve this problem is to flash the BIOS on the affected workstation to set a unique SMBIOS guid. Contact the PC vendor for the tool to do this.
  
  
• The machine is linked to an obsolete object on the server
  
  This can happen if you have "Automatically create new client records for duplicate hardware IDs" set in the Advanced tab of your site properties. The solution to this one is to manually delete those obsolete objects.
  
  
• The machine was imaged using a technology such as Ghost, but the SID and/or SCCM client guid were not reset
  
  This can be a bit of a pain to troubleshoot on the server - I once saw a machine that according to the SCCM reports had 30 separate users logging into it. Since this machine was kept in a locked office, this appeared to be a bit odd. It turned out the support team had used Ghost to image one of their machines and then deployed this image to all the machines in their department.
  
  This highlights a wider point in deploying SCCM in your environment - the process and procedures that worked in the past may need revising. In this case, they'd never had a problem before because their authentication was handled by Netware.
  
  The easiest way to fix this problem is to power off the machine, delete the computer object in SCCM, recreate the record manually then PXE build the machine.
  

Other pre-Windows PE errors

• \Boot\BCD error
  
  Assuming you can get past abortpxe.com, there is another error you can see at this stage. After pressing the F12 key to PXE boot you can sometimes see
  
  
  
Windows Boot Manager (Server IP: x.y.z.a)

Windows failed to start. A recent hardware or software change might be the cause.

File: \Boot\BCD
Status: 0xc000000f
Info: An error occurred while attempting to read the boot configuration data.

  
  The simple solution is to delete the computer object and recreate it, which should fix this problem. I've only ever seen this problem with SCCM 2007 SP2 when deploying Windows 7.
  
  This does look like a bcd error, but in the SCCM implementation of WDS there is no single boot.bcd file, the boot.bcd file is created on the fly in the RemoteInstall\SMSTemp folder with a name of year.month.day.hour.minute.number.number.guid.boot.bcd.
  
  If anyone knows the actual fix for this (without having to delete the computer object) please post in the comments!
  
  
• Only using 32-bit boot images when you have 64-bit machines in your environment
  
  Again, this one seems a bit odd. If your workstation is 64-bit (and you'd be hard pressed to find a non-64-bit machine these days), then you need the 64-bit boot files available - even if you are only deploying 32-bit Windows, and are using a 32-bit boot image. The 64-bit boot files are extracted from the boot image and used during the initial PXE process, so if they're missing, you won't be able to PXE boot a 64-bit machine.
  
  If you're getting this error, you'll see something like this in smspxe.log
  
  The SMS PXE Service Point does not have a boot image matching the processor architetcure of the PXE booting device.
  
  

Troubleshooting PXE in SCCM OSD Part 2

Troubleshooting PXE in SCCM OSD Part 1
Troubleshooting PXE in SCCM OSD Part 3 Troubleshooting the TFTP Service
PXE-E32: TFTP Open Timeout

Assuming your client gets an IP address, there is still a large number of ways for it to fail before you even get an abortpxe.com message. PXE-E32 TFTP open timeout can be a frustrating message - but it does at least give you a clue where to look.

This error means that your client machine can't access the TFTP daemon running on your PXE Service point. Assuming your PXE Service Point is set up correctly (check the WDS service is running), the most common reason for this message is network filters/firewall settings. Fortunately, Microsoft provide a document which lists what ports need to be open for the TFTP daemon to work. Read this document carefully, you need to open more than just ports 69 and 4011 to get this to work. The daemon listens on port 69 but responds on a randomly chosen high port. You'll need to configure the network filter rules to allow this behavior before TFTP will work.

You might also see this error if DHCP is misconfigured. If you have DHCP and the PXE Service point on different servers then you'll need to set option 66, the Boot Server Host Name. A small tip here - use the IP address of the PXE Service Point when troubleshooting this setting - this removes the possibility that it's a DNS resolution issue. You can always set it back once you're happy everything is back working.

PXE-E53: No boot filename received

Check option 67 on the DHCP server. It should be something like

smsboot\x86\wdsnbp.com

PXE-E55: ProxyDHCP service did not reply to request on port 4011

Related to the TFTP timeout problem, this suggests a firewall or routing issue. Check the firewall settings allow 4011 UDP through.

If the client and the PXE Service Point are on different subnets, check that the traffic is being forwarded from the client subnet to the PXE Service Point.

PXE-E3B: TFTP error file not found

At this point we know the client is getting service from DHCP and has managed to find the TFTP server and request the boot file. Two things to check here are

1. Option 67 is configured correctly and pointing to a file that exists on the server
   
2. The files are actually on the TFTP server
   

Check the SMSBoot folder in the reminst share on the PXE Service Point. There should be 3 folders in the SMSBoot folder - ia64, x64 and x86. Each folder should contain some boot files. If not, you have problems!

The missing boot files can be fixed in a number of ways. The easiest way is to just copy the correct files over from a working PXE Service Point. I would not recommend this though - the files are missing for a reason, and you should really fix the underlying cause.

This error can be caused by a number of things- updating drivers in the default OSD Boot Images, restarting the server hosting the PXE Service Point or just a botched PXE Service Point install. The first thing you should try is clearing out temp files used by PXE.

• Stop the WDS Service
  
• Delete (or move) the folder %temp%\PXEBootFiles
  
• Start the WDS Service
  

If this doesn't work it might be a more fundamental problem with the PXE Service Point. Remove the role from the server, restart the server hosting the PXE Service Point and Add the role back.

Troubleshooting PXE in SCCM OSD Part 1

PXE booting makes deploying OS images much simpler for end user technicians. There is a lot that can go wrong though, especially if you're attempting to run it in a high security, heavily filtered network.

In the next few blog posts I'll cover how to go about troubleshooting PXE errors in OSD.

When a PXE failure occurs it helps to be very precise with the step it failed at. The place at which a PXE build fails can tell us where to investigate.

Some possible causes of error in a PXE build are-

• Workstation BIOS configuration and/or lack of RAM
  
• Duplicate SMBIOS id (typically seen on older hardware)
  
• DHCP Server configuration
  
• Network filters / configuration
  
• WDS service failure
  
• PXE service point failure
  
• Wrong collection membership in SCCM
  
• WDS cached collection membership
  
• Obsolete objects in SCCM
  
• Network drivers for Vista/7 are available, but not for XP
  
• Network drivers are not available for Vista/7
  

On the server side there's one log file that will help you immensely. If you have set up the PXE Service Point on the site server it can be found at

%ProgramFiles%\SMS_CCM\Logs\smspxe.log

Or, if you have configured another server as the PXE Service Point it will be found at

SMS_CCM\Logs\smspxe.log

in the root of the drive SCCM is using.

Using Trace32 to view this log file can give you realtime information on the PXE boot process. However, the first error we'll look at won't even show up in this log.

PXE-E51: No DHCP or proxyDHCP offers were received

The most common PXE error I see is PXE-E51. The first indication that something is wrong is when you see DHCP... and you get more than three or four dots.



The PXE process fails at this point with PXE-E51: No DHCP or proxyDHCP offers were received.



This error basically says that the machine can't obtain an IP address. Possible reasons for this include

1. Your DHCP server isn't working
   
2. If you use DHCP reservations you may have made a mistake entering the MAC address of this machine
   
3. You don't have a DHCP pool set up for this subnet, or the pool has no free addresses
   
4. Your DHCP server is on a different subnet and you haven't set up an IP forwader or DHCP Relay agent
   
5. The network cable or port is broken
   

Most of these problems are easy to check, or are easy for your networking people to check. Once the problem is fixed the PXE boot process works properly in most cases. Assuming your network is configured to allow PXE booting this error normally means one of two things - the cable is faulty or there's no DHCP reservation/the DHCP pool is exhausted.

This error highlights the need for preciseness in the error reports from your technicians. Since there's so much more that can go wrong at this stage, it's nice to have an error which is relatively easy to fix.

Troubleshooting PXE in SCCM OSD Part 2
Troubleshooting PXE in SCCM OSD Part 3
Troubleshooting the TFTP Service

A History of TechEd Europe in Conference Bags Part 2

Barring any last minute volcanoes I'll be at MMS 2011 next month, so I thought I'd have a look back over some past conferences I've been to. This is a continuation of the conference bag retrospective I started here.

TechEd: IT Forum 2007
13-16 November, Barcelona

SCCM 2007, Bitlocker and lots of security stuff made this a great conference. Well, that and the weather. And the food. And the architecture. And....




TechEd EMEA IT Professionals 2008
3-7 November, Barcelona

The last TechEd in Barcelona, and finally I get to the Camp Nou. A Champions League tie against FC Basel which ended 1-1. Messi scored for Barca, I can't remember who scored for Basel.

The talks from the conference are available online at msteched.com, here are some I'd recommend

Windows Security Boundaries by Mark Russinovich
Advanced Operating System Deployment Part 2 (Part 1 seems to be missing)




TechEd EMEA 2009
9-13 November, Berlin

The last European TechEd I attended was sadly the worst. I don't know what happened in the organisation of this event, but it was terrible in comparison to (at least) the five previous TechEds.

The scheduling was bad on two fronts. The first day of the conference was the 20th anniversary of the fall of the Berlin wall. While it was great to be in Berlin for such a historic event it meant hotel rooms were hard to come by and expensive. The scheduling of the talks was poor too - similarly themed talks either clashed or were at different ends of the conference center. Popular talks were put in small rooms and there were a number of hastily arranged repeat talks.

The Messe conference center was nice, but they obviously didn't have enough room. Corridors were packed during transitional periods and some rooms didn't even have four walls. Some of the rooms had a curtain separating the auditorium from the corridor making it difficult to hear the speaker.

Bottled water was no longer available, instead provided by water coolers. Unfortunately there were no cups and they didn't have enough water bottles to supply with the conference bags.

Berlin as a city was great (I'd recommend the currywurst if you're visiting).

It's a pity the conference organisers had a nightmare.

A History of TechEd Europe in Conference Bags Part 1

I'm off to MMS 2011 next month so I thought it would be fun to look back over the Microsoft conferences I've attended in the past. I've dug out the old conference bags from on top of the wardrobe - excuse the dust!

TechEd Europe 2004
29 June - 2 July, Amsterdam

Held in the Amsterdam RAI, this was the first major conference I attended. Some of the key topics covered were the additional security features of XP SP2, Windows ACS (which ended up in SCOM) and running Server 2003 on 64-bit hardware.

Sadly, the conference bag was possibly the worst ever conference bag in the history of conference bags. A bright orange courier bag with a special hook to hold your drum(!). I'm assuming the orange was to help you remember you were in the Netherlands, and the drum... believe it or not, the drum was handed out as part of the keynote. It was fun coming back through customs with this.



TechEd Europe 2005
5 - 8 July, Amsterdam

Again held in the Amsterdam RAI, the big topics in 2005 (for me) were WSUS, LTI and ZTI with BDD and security.

Looking at the bag, it would appear that SQL Server 2005 was a big deal this year. The bag seems a bit conservative compared to 2004!



TechEd: IT Forum 2006
14-17 November, Barcelona

The IT Forum and TechEd events merged in 2006 and TechEd: IT Forum was born. The conference center in Barcelona was excellent, but not quite as good as the RAI in Amsterdam.

I went to a lot of talks about Vista. This was sadly a waste of time thanks to the pain that was/is Volume Licensing 2.0. The original Reduced Functionality Mode in Vista made it impossible for us deploy Vista - we weren't prepared to take the risk that someone's workstation may end up a glorified web browser. Security talks were high on my list again this year - they were not only useful, but helped with the CISSP CPE credits!

A simple check to see if the TPM is enabled

The Deployment Guys have an interesting post on how to check if the TPM chip is enabled and activated as part of a task sequence (see here).

When we deployed Windows 7 we ran into the same problem. Our solution was a bit simpler!

Connecting to root\cimv2\Security\MicrosoftTPM and executing

select * from win32_tpm

will only return a value if the TPM is enabled. This can be added as a condition in your Task Sequence so that your Bitlocker steps only run if the TPM is on.



A note of caution though - this query does not check whether the TPM is activated. It only checks that the TPM is enabled.

Manually update Forefront Endpoint Protection and Client Security

Sometimes in FEP 2010 and FCS you need to force a signature update. There are two ways of doing this. Firstly, Microsoft supply a download of the latest signatures at this link

http://support.microsoft.com/kb/935934

The package you download can update both FCS and FEP 2010.

To manually start the signature update from the client software run

MpCmdRun.exe -SignatureUpdate

In FCS you should therefore run

C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\MpCmdRun.exe -SignatureUpdate

In FEP 2010 you should run

C:\Program Files\Microsoft Security Client\Antimalware\MpCmdRun.exe -SignatureUpdate

On Windows 7 you should run MpCmdRun.exe with elevated privileges or from an elevated command prompt.

Don't forget that because the path to the executable contains spaces you'll need to use quotes if run in a Run Command Line step in a Task Sequence.

Why does this MSI keep reinstalling?

Packaging up applications is one of the key tasks for anyone working with OSD. Creating software packages can be pretty easy, especially if the app is supplied as an MSI. Most of the time it's as simple as running something like

msiexec /i Setup.msi /qb ALLUSERS=1

Occasionally though, you'll run into problems. We had an app that seemed to install successfully. However, each time the app was run, the MSI ran through some checks and appeared to try to repair the app.



After a bit of digging it turned out that the problem was being caused by an advertised shortcut. Each time the app was run, the advertised shortcut kicked off an auto-repair, even though the app was installed successfully. The quick (and probably nasty solution) was to install the app without the advertised shortcut

msiexec /i Setup.msi /qb ALLUSERS=1 DISABLEADVTSHORTCUTS=1

In situations like this it's probably better to return to the vendor and ask for a working MSI, or to use a tool like Orca to discover what is causing the auto-repair to kick in.

XP Mass Storage Drivers on Toshiba Laptops

A common way of installing Mass Storage Drivers for XP is to add a condition in your Task Sequence to query the Model of the machine and apply the relevant driver. The Deployment Guys have a great post on how to do this here.

The basic idea is that you have a step in your task sequence to apply (for example) the Intel(R) PCHM SATA AHCI Controller 4 Port driver.



On the options tab you would have a number of WMI queries which identify the machines that need that driver. In this example you'd probably see things like-

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Satellite Pro L500%"
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Satellite Pro U500%"
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Latitude E5410%"
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Latitude E4310%"




Unfortunately this type of driver application assumes that there is one chipset per model (in the above example, the Intel HM55 Chipset). This is not always the case. Take the Toshiba Tecra A11.

Some Tecra A11 models have the Intel HM55 chipset. Some have the Intel QM57 chipset. On both models, running the following code would return TRUE-

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Tecra A11%"

So, how do you identify the revision of the Tecra and therefore the chipset, in your task sequence? You need to query for the partnumber instead of the model. Toshiba store the partnumber of the laptop in Win32_ComputerSystemProduct. In this case the following code would return true for the Tecra A11 with an HM55 chipset-

SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTSE0E%"




Here are the SELECT statements to use for some of the other Toshiba laptops in the current range.

Toshiba Tecra A11 (Intel HM55 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTSE0E%"

Toshiba Tecra A11 (Intel QM57 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTSE1E%"

Toshiba Tecra M11 (Intel HM55 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTME0E%"

Toshiba Tecra M11 (Intel QM57 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTME1E%"

Toshiba Portege R700 (Intel HM55 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PT310E%"

Toshiba Portege R700 (Intel QM57 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PT311E%"

So, adding the Toshiba HM55 models to the above example would give us this

Using DISM to fix a broken Windows 7 image

The best way to create your gold image is by running a build and capture in a virtual machine. The reason for this is that you don't get extra drivers hanging about in your image.

One of our team accidentally created a fresh image on real hardware. This image worked fine on most models, but failed on a Toshiba Tecra A11. After a long investigation it turned out that the image contained an old Intel network driver that would not work on the Tecra. Even though we had the new driver in our driver store, the Tecra would always choose the driver in the image. Not having a working network driver during OSD is a bit of a problem!

The solution is to use DISM to remove the drivers from the image*.

First of all, make a copy of your image and work on this copy. Once you've done this you need to mount the image. From an administrative command prompt run the following commands-

mkdir C:\mountfolder

dism /mount-wim /wimfile:yourwimfile.wim /index:1 /mountdir:C:\mountfolder 

Once the image has been mounted, run the following

dism /image:C:\mountfolder /get-drivers 

This should show you all the extra drivers that have been added to your image. The drivers will be listed as oem1.inf, oem2.inf and so on. Here's the sample output from an image I recently had to edit-

Deployment Image Servicing and Management tool

Version: 6.1.7600.16385

Image Version: 6.1.7600.16385

Obtaining list of 3rd party drivers from the driver store...

Driver packages listing:

Published Name : oem0.inf
Original File Name : prnms001.inf
Inbox : No
Class Name : Printer
Provider Name : Microsoft
Date : 21/06/2006
Version : 6.1.7600.16385

Published Name : oem1.inf
Original File Name : prnms001.inf
Inbox : No
Class Name : Printer
Provider Name : Microsoft
Date : 21/06/2006
Version : 6.1.7601.17514

Published Name : oem2.inf
Original File Name : sthda.inf
Inbox : No
Class Name : MEDIA
Provider Name : SigmaTel
Date : 09/08/2005
Version : 5.10.4647.0

Published Name : oem3.inf
Original File Name : sthda64.inf
Inbox : No
Class Name : MEDIA
Provider Name : SigmaTel
Date : 09/08/2005
Version : 5.10.4647.0

Published Name : oem4.inf
Original File Name : b57nd60a.inf
Inbox : No
Class Name : Net
Provider Name : Broadcom
Date : 02/12/2010
Version : 14.4.2.2

Published Name : oem5.inf
Original File Name : k57nd60a.inf
Inbox : No
Class Name : Net
Provider Name : Broadcom
Date : 02/12/2010
Version : 14.4.2.2

The operation completed successfully.

To remove, for example, the Broadcom k57nd60a.inf driver, just run the command

dism /image:C:\mountfolder /remove-driver /driver:oem5.inf 

You should see dism reporting success

Found 1 driver package(s) to remove.
Removing 1 of 1 - oem5.inf: The driver package was successfully removed.
The operation completed successfully.

Once you've removed the drivers you want, unmount the image and commit the changes

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

And that should be that. Create a new OS install package and test your image. Once you're happy you can use that image instead of the original.

*Of course, the real solution is to recreate the image in a VM, but that's not always practical!