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