SCCM 2012 RC2 released

Microsoft have released the open beta of Configuration Manager 2012 Release Candidate 2. It can be found at http://www.microsoft.com/en-us/server-cloud/system-center/configuration-manager-2012.aspx.

Uninstalling the SCCM Client

The only supported method of uninstalling the client is ccmsetup /uninstall (See Technet).

On most systems this executable is found at C:\WINDOWS\system32\ccmsetup

But since Operating System Deployment relies on the SCCM client, how do you uninstall it as part of a task sequence? The answer is simple - schtasks.

The following command should work as the last step in a task sequence-

schtasks /create /tn "Remove SCCM Client" /tr "C:\WINDOWS\system32\ccmsetup /uninstall" /sc ONSTART /Z /ru "SYSTEM"

It should work, but I've not tested it. It's one of those things that was a requirement, but was quickly dropped, so never even got into testing.

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.