MDT: Notes on setting Pre-checked Applications in CustomSettings.ini

I recently needed to set some conditions in my MDT CustomSettings.ini file to pre-check certain applications during an image deployment. Those of you that have used this feature know that you can get the GUID from any application in MDT by right-clicking it within the MDT Workbench view and choosing properties. The GUID appears at the bottom of the window that opens and it can then be copied and pasted into then CustomSettings.ini like so:

Applications001={GUID1}
Applications002={GUID2}

Thats fine and dandy, but what are the limitations of this process? What syntax is permissible? I won't go into the details but some recent issuues froece me to ask those quetions. Here's the answer I got from Keith Garner on the MDT Technet forums:

Numbers may be between 1 and 999

You can start at any number within the CS.ini *HOWEVER* when reading the list, MDT will always start at 1, and if it comes across any missing number it will ignore the rest. So if you inputted Var10, without using Var1 through Var9, then Var10 might as well not existed.

You may choose to *not* prefix a zero to the start, or you may choose to prefix some zeros, as long as the number is 3 digits long, like: 001, 010, 100.

Valid:
Applications1=GUID
Applications10=GUID
Applications010=GUID

Not Valid:
Applications01=GUID
Applications0001=GUID

I did some testing on my own and (as expected) these rules also apply to MandatoryApplications, WMU_EXCLUDEID and WMU_EXCLUDEKB. All good info to know if you are customizing these settings in CustomSettings.ini!

MDT: Disable Automatic Updates at initial deploy with Unattend.xml

Windows 7 has a tencancy to automatically install a few updates right after a fresh

install (regardless of its default settings). You can suppress this behavior by 

editing the value specified for the variable <ProtectYourPC> in the unattend.xml for 

Windows 7 task sequences for Windows 7 deplyoments. Here are the possible values:

1 - Specifies the recommended level of protection for your computer.

2 - Specifies that only updates are installed.

3 - Specifies that automatic protection is disabled.

NOTE: Option "3" is usually the best choice if you already have an internal WSUS.

MDT: Change the Windows product key quickly with Unattend.xml

Here's a quick and easy way to change the product key for an OS in MDT:

1. Use Notepad++ or some other advanced text editor to open the following:
   "<MDTSharePath>\control\<TaskSequenceId>\unattend.xml"
2. Locate your product key under the "<ProductKey></ProductKey>" entry. 
3. Replace the key under that entry with your updated product key and save the file.

MDT: Important FYI regarding the new GPO Pack feature

Its been covered at other sites, but I recently ran afoul of this so I'll cover it here. By default in MDT 2012 you may find Windows Firewall settings disabled by group policy after deploying certain OSes. Firewall settings will be greyed out and the following message is displayed in the Windows Firewall interface after deployment:

"For your security some settings are managed by your system administrator"

The computers will not have been domain-joined yet and you will not have set up any manual tasks to apply local policies. So what is the culprit? Actually  it’s a new feature in MDT 2012! You can add the following to Customsettings.ini to disable it:

ApplyGPOPack=NO

This should resolve the issue. Unfortunately Microsoft did not just add the new feature to apply local polices during a Task Sequence. They also added four GPO Pack templates which get applied *by default* during a deployment! You can find these templates in your Deployment Share folder in the subfolder "\Templates\GPOPacks". As of the day these notes were written the current templates are as follows:

<MDTShare>\Templates\GPOPacks\
|
|_\Win7SP1-MDTGPOPack
|
|_\WinVistaSP2-MDTGPOPack
|
|_\WS2008R2SP1-MDTGPOPack
|
|_\WS2008SP2-MDTGPOPack

Going from MDT to SCCM is not as easy as I thought...

We've been using MDT for OS Deployment internally at my company since version 2008. Although MDT supports a SQL database I never had a real need to use one. Because of the successes we had with MDT we thought a leap to SCCM would not be too much of a stretch. Boy were we wrong. SCCM is powerful, but its also really complicated and dense. If you are using MDT and thinking about getting your feet wet with SCCM make sure you brush up on SQL, WQL and WMI. With all the SQL and WQL I've been writing lately I feel more like a DBA than a SysAdmin...

Lots of great new 2012 releases from Microsoft...

Looks like 2012 will be a busy year for Microsoft SysAdmins. Microsoft has been on a roll here lately with the System Center and MDT product line. Check out these three great tools from Microsoft that just went RC1 or Beta 2:

System Center 2012 - Configuration Manager:

http://www.microsoft.com/en-us/server-cloud/system-center/configuration-manager-2012.aspx

System Center 2012 - Operations Manger:

http://www.microsoft.com/en-us/server-cloud/system-center/operations-manager-2012.aspx

Microsoft Deployment Toolkit (MDT) 2012:

http://blogs.technet.com/b/deploymentguys/archive/2011/11/11/mdt-2012-beta-2-released.aspx

I have high hopes of successfully rolling these out at my company in 2012. If you're a SysAdmin working in a Windows environment, I suggest you make similar plans.