Configuration Manager 2012 Licensing

I went to the System Center 2012 Preview Roadshow in Edinburgh yesterday. Sadly, this wasn't one of Microsoft's best events (it was pretty awful), but there was one bit of information they presented that I hadn't noticed before.

There are some big changes with the way the System Center products are licensed with the 2012 release. Gone are the days when you could licence Operations Manager or Configuration Manager separately. All the products are bundled together and there are only two options for licensing now-

• System Center 2012 Datacenter Edition
• System Center 2012 Standard Edition

Both products give you the entire System Center suite - Operations Manager, Config Manager, DPM, VMM, Service Manager, Forefront Endpoint Protection and the two new guys Orchestrator (formerly Opalis) and App Controller (formerly project Concero). The only difference (apart from price) is that the Datacenter edition allows you to install as many virtual machines as you want on a two core server - the Standard edition is stuck at two VMs.

On the client side, the Core CAL will still give you ConfigMgr and Forefront Endpoint Protection. The Enterprise CAL adds DPM, OpsMgr, Orchestrator and Service Manager.

SQL Server 2008 R2 in a task sequence

When packaging up software for SCCM I like to find a silent install switch that shows some kind of progress bar. This has the obvious benefit of providing feedback during testing, but can cause unexpected problems. Like when installing SQL Server 2008 R2 Express.

There are 2 silent install parameters for SQL Server 2008 R2-

• /Q - quiet install with no user interface
• /QS - quiet install but with progress dialog

I'd normally prefer to use /QS so I can see what is going on during testing. However, this is the result of my testing with SCCM-

• /Q - works fine in a Task Sequence
• /QS - doesn't work at all

So, if you're having an issue with installing SQL Server 2008 R2 (and 2008 R2 Express), try using /Q instead of /QS.

The other issue that I saw with the install is that the command line can be longer than 255 characters and this is a hard limit in the Program Command Line box in SCCM. The solution to this is to copy the command line into an install.cmd file and run that instead. This allows you to have command lines like this-

SQLEXPR_x86_ENU.exe /ACTION=INSTALL /FEATURES=SQLEngine /INSTANCENAME=MyInstance /SQLCOLLATION=Latin1_General_BIN /SQLSVCSTARTUPTYPE=Automatic /SQLSVCACCOUNT="NT AUTHORITY\NETWORK SERVICE" /SQLSYSADMINACCOUNTS="BUILTIN\ADMINISTRATORS" /IAcceptSQLServerLicenseTerms="True" /Q

Automatically delete roaming profiles on workstations

If you're running a pre-Vista OS and have roaming profiles enabled you have probably noticed that Windows will cache those profiles on workstations. This is great if it's your primary machine as you don't need to download the entire profile every time you log in, but can be a real pain for lab style machines. If you have enough different logins your workstations can run out of disk space!
One of the solutions to this is to run Delprof. This is a Microsoft utility that will delete inactive profiles. A sample command line is

delprof.exe /I /Q /D:30

The above command will remove inactive profiles that are over 30 days old. Depending on the traffic on your machines you may wish to increase this value. But what is the best way of running this command?

I'd recommend deploying this using schtasks. This allows you to run delprof when the machine is idle - I've seen corruptions occur when delprof runs at logon or logoff, so this is probably a safer way. I run the following batch file on each workstation -

copy delprof.exe c:\windows\system32

schtasks /create /tn "Delete Inactive Profiles" /tr "delprof.exe /I /Q /D:5" /sc ONIDLE /i 5 /ru "SYSTEM"

Delprof is available from the Microsoft download center (www.microsoft.com/download/en/details.aspx?id=5405).

Fixing broken SMSSLP settings

MadLuka has a great post here about some issues related to the R3 upgrade for the SCCM client. Basically, deploying this hotfix without respecifying the correct parameters can knock out your SMSSLP settings on your clients. This is not an issue if your clients can find the management point using WINS, DNS or Active Directory, but is a massive issue if you have workgroup clients that don't use these technologies.

Our fix was to roll out the registry key HKLM\SOFTWARE\Microsoft\CCM\SMSSLP to all affected machines and this fixed the issue.