How To Execute Scripts in a Task Sequence Without a Local Disk

A common practice for OSD task sequences is set the advertisement to “run from server”.  Recently there was a situation in which the advertisement needed to be set as “download content locally”.  But there were scripts which needed to be executed BEFORE a disk partition existed, so the task sequence would fail with error code 0x800700a1 because there wasn’t a local disk in which to save the files.

There are a few ways to workaround this situation.

1.  If possible, have the advertisement/deployment configured to run from server

2.  Use DISM.exe to add the scripts into the boot image(s) (or use GImageX), then have a Run Command Line task to execute the scripts.
Note: the challenge with this method is it’s a bit tedious to maintain those scripts.

3.  Use the “Connect To Network” task to map to a network drive, then have a Run Command Line task to execute the scripts.
Note: the challenge with this method is the possibility of scripts running across the WAN, which could be less than ideal if the scripts or installers are large or if the network files are not available.

Custom query of ACT data for apps with issues

The application compatibility toolkit (ACT) is a great tool for analyzing compatibility of apps when doing a migration of Windows.  However, the available “reports” are limited in what they display out-of-box.  Fortunately since the tool is a SQL database, we can write our own queries to get what we need.  The below procedure/query will identify business specific apps and the detected compatibility issues.

1. Create and customize an ACT query (within the compatibility manager) which identifies your specific business software
2. Select all of the apps listed
3. Create a new custom category “Priority Business Apps”
   • For the primarily used business apps, create/select sub category “PrimaryApps”
   • For the secondarily used business apps, create/select sub category “SecondaryApps”
     
4. Run the following query against the ACT database

   Select distinct CAQ.subCategory, AR.AppName, LI.issueID, AIQ.severity, LI.title, LI.Details
   from Applications AR
   join AppReport_Issues_Query AIQ on AIQ.appID=AR.identity_hash
   join Categorized_Applications_Query CAQ on CAQ.objectID=AR.identity_hash
   join Localized_Issue LI on LI.issueID=AIQ.issueID
   where CAQ.category='Priority Business Apps'
   

5. Copy the results into Excel

Standalone Imaging Solution

I’ve been in a situation a couple of times where a client was going to use a third-party vendor to image hardware offsite, but didn’t have Microsoft deployment tools (WAIK, WDS, MDT, SCCM, etc.) for deploying the standard WIM image that was created.  To work with this scenario, I developed an unattended answer file with WSIM that can be used to sysprep a computer for an image where the disk can be cloned.  This sysprep file essentially does the following items below.  Many of the items may seem “unnecessary”, but they are necessary in order to automate the majority of the deployment.

Sysprep.xml Features

• enables the local admin account
• removes the “copy profile” functionality
• removes the “Get Windows Live” shortcuts
• sets the time zone to MST
• enables RDP
• disables firewall notifications
• disables the domain firewall
• disables Windows Defender
• disables IE accelerators
• disables the IE first run wizard
• enables IE compatibility mode
• disables IE suggested sites
• sets Windows to skip auto activation
• disables system restore
• sets the local language to English
• sets the registered owner/org
• sets Windows to automatically login as Administrator one time
• sets the screen resolution to 1024×768
• sets the first logon command to execute a script in C:\CompanyName
• Hides the Windows EULA Hides the wireless network setup wizard
• sets the default network location to “Work”
• sets the recommended level of protection for Windows Update
• creates taskbar links to Outlook and Word

Download sysprep.xml here!!

Next, the overall process looks like such:

1. Automate driver installation using HP SoftPaqs and script to copy the files into C:\CompanyName\ModelName\
   1. Optionally, automate and script BIOS updates
2. Create script named “ImageConfigTasks.vbs” (code below) to do the following items (this will run post sysprep).  Script should be copied into C:\CompanyName.  You can use the attached script as a starting point.
   1. Prompt for PC name
   2. Detect PC model and install drivers (do this next to ensure the NIC driver gets installed for the domain join)
   3. Join to domain and OU
   4. Install SCCM client
   5. Install SCEP client
   6. Restart Window
3. Create sysprep.xml file with x64 bits which essentially allows the PC to auto logon into Windows with the admin account and launches ImageConfigTasks.  You can use the attached sample as guidance, but do not actually use this file as it was compiled for the x86 components and you need it for x64.
4. Create a “build” task sequence which installs Windows, software, security updates, copy of the drivers into the CompanyName folder, copy of the ImageConfigTasks script, copy the sysprep.xml file
5. Run the task sequence on a VM
6. After completion, login to Windows and run %SYS32%\sysprep\sysprep.exe /generalize /oobe /shutdown /unattend:C:\CompanyName\sysprep.xml
   1. This will sysprep the PC’s disk for cloning.  Do not power on the PC once its shutdown!
   2. Optionally, you can creatively automate this process so that you do not need to actually login to the PC
7. Once the PC with the cloned disk has been delivered onsite, power on the PC.  Windows will go through mini-setup to install generic devices.  Then Windows will auto logon to run the script and complete the setup process.

Download the ImageConfigTasks script here!!

Run on physical hardware

To build-out this custom solution for the vendor, do the following.

1. Complete and “certify” the newly captured image (note: this is still in progress as of 12:15 PM today, but is looking good to complete successfully).
2. Use the deployment task to install this image AND the hardware drivers AND any other software/configurations that did not make it into the image.  You may also want to change the task sequence to NOT join to the domain for this model so that it does not receive [junky] group policies.
3. Once that task sequence is done, login to Windows as the local admin account.
4. Ensure the two script files live in C:\CompanyName
5. Run %SYS32%\sysprep\sysprep.exe /generalize /oobe /shutdown /unattend:C:\CompanyName\sysprep.xml
6. DO NOT TURN THE COMPUTER ON.  Remove the hard drive and give to vendor.  Once a cloned PC is onsite and connected to the network, only then should the PC be turned on.  A prompt for the computer name will appear and then the custom script will execute.

While you’re in the process of testing/development, you can of course turn it on to validate the scripts execute, drivers are installed, etc.

Automating the Windows 8 Startup Background Image

*** Update 11/26/12 – KB2770917 now provides administrators with the ability to modify the default background as well, without needing to perform the below steps within WinPE ***

Automated deployment and configuration of Windows 8 is much like that in Windows 7.  I can easily see many organization not caring for the default Windows 8 background startup image and wanting to replace it with one of their own.  In a TechNet posting, one person had gone through a series of painful scripts to take ownership of a folder, propagate the permissions, etc.  While this could still accomplish the task, many of the steps seem unnecessary.  The easiest method that I found to change the default image was to replace the initial file while the ConfigMgr 2012 imaging process was still within WinPE.  In this way, the files are not locked by any permissions.

To do this:

1. Create or find the image that you desire to use.  Save it as a .png file type.
2. Create a script to execute the below command to replace the image.  (Side note: if you want to retain the old image, then add an extra entry into your script to rename the img100.png file)
   if exist C:\Windows\Web\Screen\img100.png xcopy “%~dp0MyCustomStartupBG.png” C:\Windows\Web\Screen\img100.png /Y
3. Execute the script in a task sequence with a Run Command Line step.  Place this immediately after the Apply Operating System step!
   
4. At completion of your task sequence is your custom startup background image!

Creating Windows 8 Start Tiles with WSIM

Automated deployment and configuration of Windows 8 is much like that in Windows 7.  The Windows System Image Manager (WSIM) can be used to create an unattend.xml file for use in a ConfigMgr 2012 task sequence.  Keep in mind that deployment of Windows 8 is limited to MDT 2012 and/or ConfigMgr 2012.  To get the version of WSIM that supports Windows 8, you’ll need to download/install the Windows Assessment and Deployment Kit v8.

Windows 8 has the new “Start Tiles” which replaces the old Start Menu that dates back 18 years with Windows 95.  One thing that you may need to do as part of your automated deployment is create new Start Tiles.  In the WSIM, add into the “Specialize” pass, item Microsoft-Windows-Shell-Setup >> Start Tiles >> Square Tiles >> SquareOrDesktop Tile1 (then Tile2, 3, 4, etc.).  In the below example, I have added a tile for Microsoft Word 2013.

There are a few things to note when configuring these values:

1. The path must be hard-coded, you cannot use environment variables such as %ProgramData% instead of C:\ProgramData
2. Your drive letter must be correct.  If MDT ‘accidentally’ assigns the drive letter to E:\ then this will not work (see point #1)
3. You must point to a link (.lnk) file.  Trying to use the executable name (such as WINWORD.exe) does not work

ConfigMgr 2012 “Protected Boundaries”

A best practice in ConfigMgr 2007 was to have remote distribution points “protected” so that client in other subnets would not incidentally download content from them.  This was particularly important for DPs that were slow WAN links.  In ConfigMgr 2012 however, having a protected DP looks different.  Instead of the old checkbox on the DP settings, now you add the Boundary (IP address range/subnets or AD Sites) into it’s own Boundary Group.  In this way only clients in that subnet will pull from that DP.

 

Reporting Services Site Role Setup: Instance Blank/Empty

When attempting to set up and configure the ConfigMgr 2012 site system role for reporting services, a frequently experienced “problem” is that the instance name can be blank/empty in the wizard and thereby unable to proceed with the wizard.  This usually occurs when SRS has not been pre-configured properly.

While it is common “knowledge” that the reporting services database needs to be created first, an oft-overlooked step is to use the Reporting Services Configuration Manager to create the virtual directories for IIS.  And it is these steps which need to be completed to get you on your way.

1. Open Reporting Services Configuration Manager
2. Connect to the server/instance
3. Click on Web Service URL – make a fake change, such as changing the name of the virtual directory and then putting it back to ReportServer – and clicking Apply.  This will then create the new virtual directories.
   
4. Click on Report Manager URL – again, make a change to the name and put back to just Reports – and click Apply to generate the new virtual directories.
5. Close configuration manager
6. Return to the CM12 site role setup program, click “Verify” for the database connection, and voila the instance is now populated correctly!

VirtualBox NIC for WinXP, Win7, and WinPE

I’ve been using VirtualBox lately for doing some lightweight virtualization to test various deployments.  Most recently, I was using it to test USMT hardlink migration in going from WinXP to Win7.  So after a quick setup of a WinXP test VM and installing the VM additions, I found that the network drivers were not present in WinPE.  So I added the network drivers into WinPE (in SCCM) and updated the SCCM distribution points.  The NIC still didn’t work in the VM.  So I used a different NIC that worked WinPE and Win7, but it didn’t work with WinXP even though the VM additions were installed (I don’t understand why the drivers are not included!).

Anyhow, if you need to use VirtualBox for the same kind of testing, I recommend configuring your VM as follows:

1. Create your WinXP VM
2. Configure the VM to use Bridged network and emulate the Intel MT Desktop device
   
3. Configure the VM to auto mount a shared drive on the host computer (for quick access to files)
   
4. Download the NIC drivers from Intel online to that shared folder
5. Install the NIC drivers on the WinXP VM.

Now you have a VM that works with WinXP, Win7, and WinPE!

Migration Strategy for WSUS to SCCM & Software Updates

The key to protecting an environment from incidental patching during a transition from using WSUS to using SCCM with Software Updates is to reconfigure three group policies which have an impact on SCCM software updates.

• Specify intranet Microsoft update service location: the SCCM client sets this as a local GPO pointing to the SCCM\WSUS server.  (Note: It could be possible to set these values as domain GPO, but the trouble is that there are two SCCM servers acting as WSUS for their clients, so managing multiple GPOs would be more pain than value.)
• Configure Automatic Updates: this will set the automatic update settings.  I’ve seen that once this was turned off in GPO, it kept the default to automatically download and install updates.  It is possible to set this to Disabled without impacting SCCM’s delivery of security updates, but it will impact delivery of FEP definition updates.  With SCCM 2007 and FEP 2010, in order for definition updates to automatically install, auto approval actually gets set in WSUS itself, so therefore disabling AU would mean no delivery of those updates and need to be re-enable in the future.
• The final GPO is just configuration of the Automatic Updates windows service.  If the GPO disables the service, then no updates will work.  A forced enable of the service through GPO would be a good thing.

A route for the WSUS to SUP migration could look like this:

1. Configure Automatic Updates set to Disabled
2. Enable the AU windows service
3. Optional: continue to disable user’s ability to get updates themselves from Windows Update
4. Set all other WSUS related GPOs to not configured
5. Deploy the SCCM client upgrade/changeover
6. Later, as part of a FEP migration, use GPO to configure automatic updates to be enabled (since that will be needed for automating the definition update releases)

SCCM Distribution Points on Windows Server Core

I recently scoured the Internet for information and success/trials of using Windows Server 2008 R2 Core as an SCCM distribution point.  Much to my surprise, I found very little information and had to piece together and test it out for myself.  According to the Prerequisites for Installing Configuration Manager, a BITS-enabled DP needs IIS, BITS, WebDAV, and RDC.  Unfortunately only IIS can be installed on Server Core, and not the others.

At first glance, this seems to indicate that you wouldn’t be able to use Server Core as a DP.  However, when you look closer, the prerequisites listed are only for BITS-enabled DPs.  So none of IIS, BITS, WebDAV, and RDC are necessary.  Granted you could miss out on the advantages that BITS provides, but it is still possible to use Core as a DP.  Another possible route is to use the Server Share (setup/config similar to doing a new Server), but the disadvantage is not being able to have site status messages reported to the parent site.

Phew!  It seems so simple, yet so easy to get confused.  So when setting up an SCCM distribution point on a Windows Server Core OS, just be sure to not enable option “Allow client to transfer content using…BITS…”