Category: Deployment

Remove client from collection in OSD task sequence using Orchestrator

A common setup when using System Center Configuration Manager to deploy is to have an OSD collection which has a required deployment. Moving clients to that Collection will let them be reinstalled or installed. After deployment is done you typically want the machine removed from that collection. There are a few ways of doing that but my favorite is using an Orchestrator runbook.

Orchestrator Runbook Configuration

Note: In this guide I assume that you have installed System Center Orchestrator 2012 SP1 or 2012 R2 in your environment.

1. First you need to download and install the Orchestrator Integration for Configuration Manager which will add the items we are using to remove the machines from a Collection in Orchestrator Runbook Designer.

2. Start Orchestrator Runbook Designer and setup the connection to the ConfigMgr primary site server by going to Options > SC 2012 Configuration Manager.

3. Add a connection to your SCCM server and make sure to test the connection using the Test connection button before proceeding.

ORC23

4. Now Create a new Runbook and go to Activities > Runbook control and drag “Initialize data” to the Orchestration pane. Do the same by choosing SC12012 Configuration Manager under Activities, and then drag  “Delete Collection Rule” out on the Orchestration pane.

5. Hover over the Initialize data icon and then drag the arrow to the Delete Collection Rule. It should look like the below image.

ORC
6.  Right click Initialize Data and choose Properties. Add two details and name them CollectionID and ClientName.

ORC21

7. Right click Delete Collection Rule and choose Properties. Start by choosing the connection you created in step 3. Note: Do not type in the text as below, instead right click the area right to Collection and choose Subscribe > Published Data. Choose CollectionID and click OK. Repeat for Membership Rule. Choose Finish when done.

If you type in the text manually you will get this error when executing the runbook: The SMS Provider reported an error. Details: Generic failure

ORC22

8. Before proceeding I strongly recommend that you execute the runbook in test mode, supplying a client name and collection ID of a machine located in the collection you want the client removed from.

Note: Do not forget to check in the runbook after testing and when you are done, or it will fail to execute during operating system deployment.

Task Sequence Configuration

Now that the runbook is running successfully you can use it in your Task Sequence. Note: This requires that you have integrated Microsoft Deployment Toolkit with Configuration Manager and that you are using an MDT Task Sequence.

Modify a task sequence and create a New group. The recommended section to run the Runbook is in the State Restore phase of the Task Sequence. To be on the safe side first run a “Gather”, then you must add “Use Toolkit Package” and last but not least execute the actual runbook by adding the “Execute Runbook” step.

ORC4

Also note that runbooks are run with the SCCM network access account so you must add that account to the Orchestrator user group that you have assigned, check the permissions and which group name to add to the relevant Orchestrator group in  Runbook Designer by right clicking the name of the runbook tab and then choose Permissions.

If you do not you will get this error in the  ZTIExecuteRunbook.log (where all events related to the runbooks are stored):

Unexpected response from web service. 405 Method Not Allowed
< ?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?>
< error xmlns=”http://schemas.microsoft.com/ado/2007/08/dataservices/metadata“>
<code></code>
<message xml:lang=”sv-SE”>The requested operation requires Publish permissions on the
Runbook</message>
< /error> ZTIExecuteRunbook 2014-07-03 10:01:56 0 (0x0000)

Happy orchestration and deploying!

Solution to the UUID problem when deploying Windows 8.1 using ConfigMgr 2012 R2

When deploying Windows 8.1 Machines using System Center Configuration Manager 2012 R2, me and as good as everyone ever done a Windows 8.1 deployment using CM2012R2, has seen the issue. The issue is that the first time a user log in to the deployed machine, it gives an error:

The Group Policy Client service failed the sign-in.
The universal unique identifier (UUID) type is not supported.

The problem has been seen from time to time but at last there is a solution to this elusive problem. The solution or workaround actually, is provided in KB2976660: First logon fails with “The universal unique identifier (UUID) type is not supported”.

80070002 and 80072ee2 error when deploying Windows using ConfigMgr 2012 R2

Encountered an interesting issue doing Windows 8.1 Deployment using ConfigMgr 2012 R2. A specific model was constantly failing at the very last step in the task sequence. The smsts.log revealed a few errors with the codes 80070002 and 80072ee2, failing at random files every time from the MDT Toolkit Package.

A few examples:

DownloadFiles() failed. 80072ee2.
DownloadContentAndVerifyHash() failed. 80070002.

It seems Microsoft is aware of the issue and the current workaround is to set the following variables first in the task sequence to address the problem until it hopefully will be fixed in a coming hotfix.

SMSTSDownloadRetryCount = 5
SMSTSDownloadRetryDelay = 15

After settings these variables the deployment finish as expected.

Solution to Windows 8.1 stuck at “Getting ready” during deployment

I encountered a stuck deployment at the “Getting ready” stage when deploying Windows 8.1 at a customer site the other day. None of the logs produced by the task sequence gave any indications on the problem at that stage so to find the real problem I had to turn to the Windows setup log setupact.log which is found in C:\Windows\Panther\UnattendGC.

In clear text it stated a few lines of this code. It kept on retrying to join the domain every ten seconds.

2014-03-14 10:48:23, Warning                      [DJOIN.EXE] Unattended Join: DsGetDcName failed: 0x54b, last error is 0x0, will retry in 10 seconds...

That particular problem was caused by the fact that the domain name to be joined was not entered as a FQDN in the task sequence. Note there are other causes of a failed domain join but remember that if your Windows 8.1 installation hang at “Getting ready”, examine the setupact.log and find the root cause and fix it.

Interesting to say is that this behavior seems to be different in Windows 8.1 than in previous Windows versions (at least Windows 7), where a failed domain join would be skipped and the deployment would continue leaving the machine in a workgroup mode.

UPDATE: It can also be caused by the network not having a connection at all. So check the network cable could also be a solution.

HOWTO: Prevent deploying Windows over VPN

Doing Windows deployments over VPN is not a very good idea and it will work really bad. If you are using MDT to do Windows deployments you can easily prevent deploying Windows over VPN.

The easisest way is to modify the customsettings.ini to simply not install anything if the network card’s gateway is what we define as the VPN gateway. So lets look at the default customsettings.ini before we modify it.

[Settings]
Priority=Default

[Default]
OSInstall=Y
SkipCapture=NO
SkipAdminPassword=NO
...

Now let’s look at what we will do to modify it to fit our needs. We will add a check so that the first thing we do is to check if the machine is on a VPN connection and if so not install anything. In the example we have two default gateways defined.

[Settings]
Priority=DefaultGateway,Default

[DefaultGateway]
10.0.0.1=VPN
10.0.1.1=VPN

[VPN]
OSInstall=N

[Default]
OSInstall=Y
SkipCapture=NO
SkipAdminPassword=NO
...

Happy deploying (but not over VPN)!

ERROR: “LiteTouch is trying to install applications” in MDT 2012 Update 1

I came across a rather peculiar thing with MDT 2012 Update 1 recently. MDT 2012 is pretty good at detecting when there are leftovers from previous deployments but this time it failed, and it failed hard.

LiteTouch is trying to install applications. This cannot be performed in Windows PE.
If booting from a USB Flash Disk, please remove all drives before restarting. Otherwise, ensure the hard disk is selected first in the BIOS boot order.

Oh no, I was NOT trying to install applications in WinPE :) It was a pretty plain task sequence and even recreating it with a brand new standard one did not help. However the solution was to remove the MININT and _SMSTaskSequence folders using the good old rd command with the switches /q and /s. Unfortunately I did not save the logs but the point is that if anyone hits this, there is a real easy solution.

Creating the perfect and fully automated reference image for Windows operating systems

A perfect reference image for Windows is fast to deploy, contains all security updates and all other necessary patches and possibly also applications like Office and least but not last is fully automated to achieve the best possible stability and to avoid the potential of manual errors. This guide is intended to show you how to build the perfect reference image ever made!

NOTE: I have also posted this guide to TechNet Wiki where you find an improved version of this article (although the steps in the article found below is still valid): TechNet Wiki: HOW TO: Create the perfect and fully automated reference image for Windows operating systems

There is no need to invent the wheel again as this can be achieved very easy in Microsoft Deployment Toolkit. Start by downloading Microsoft Deployment Toolkit and in the components section make sure to download and install Windows Automated Installation Kit. Start Deployment Workbench and off we go!

Note: This guide applies to everyone regardless if you are deploying Window using SCCM, MDT or any third party deployment solution.

1. In Deployment workbench create a new share for creating the reference image so start by creating a new one and name it like “Reference image build and capture share” or something of your choice.

2. Add the OS install files (repeat for each OS you want to build for) into the operating systems folder. Always include the setup files so never install just a WIM file at this stage.

3. Create a task sequence based on the Standard client task sequence (repeat for each OS you want to build image for).

4. For each task sequence edit the task sequence to enable the existing but disabled “Windows Update” step(s).

5. Edit the rules of the share by right clicking it and choosing Properties. The rules (customsettings.ini) should look like below. Replace the variables BackupShare and BackupDir with whatever the share name and directory to store the images are.

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipAppsOnUpgrade=YES
SkipCapture=YES
DoCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipUserData=YES
SkipTimeZone=YES
SkipFinalSummary=YES
SkipSummary=YES
SkipLocaleSelection=YES
SkipDomainMembership=YES
SkipComputerName=YES
SkipBitlocker=YES
SkipApplications=YES
ComputerBackupLocation=NETWORK
BackupShare=\\server\share
BackupDir=Captures

6. Modify the bootstrap.ini to look like the below information. Replace the variables according to what applies to your configuration.

[Settings]
Priority=Default

[Default]
SkipBDDWelcome=YES
DeployRoot=\\server\share
UserDomain=CONTOSO.COM
UserID=username
UserPassword=password

7. Now add to the Rules (customsettings.ini) a section named like below. This sets that the Windows Update step will point to your WSUS server, where you are in control of everything that is released by Microsoft and thereby staying 100% in control of what is in your image.

WSUSServer=http://nameofwsusserver

8. To make sure that you get a separate name for each operating system you are building a reference image for edit each task sequence to contain a Task Sequence Variable named for instance:

BackupFile=Windows7Enterprisex64.wim

9. Update the deployment share to get boot ISO which you use to boot your virtual machine and start the build process.

Remember to always build the reference image on a virtual machine to avoid potential problems related to hardware.

You could also add the Office as an application in the Deployment Workbench and to all task sequences that require it to make sure that you have a rapid deployment image ready to go.

Done! Happy deploying!

HOW TO: Replace WinRE with DaRT 7.0 locally and enable remote connections before supplying local administrator account information

This guide will take you through the necessary steps to create a DaRT 7.0 installation locally (replacing WinRE) and not having the user need to enter the password for a local administrator account before having the remote connection start. Basically this means that a user can press F8 during boot and choose “Repair your computer” and have someone remotely taking control over their machine and fixing problems which previously required physical presence of IT staff.

Note: There is information on how to do this in official MS documents for DaRT 7.0 but you have to do a lot of reading between the lines so I wanted to take the moment to do a complete documentation on how to accomplish this.

Background on WinRE and local admins

Some basic information about WinRE is that whenever you start WinRE (and that includes DaRT 7.0) when it is located on the machines disk it will always ask you to supply a local admin account information. This is not the case if you boot WinRE or DaRT from USB, DVD, CD or via PXE boot, then you do NOT have to enter a local admin account to gain access to the system. Potential security issue here I might add.

Step by step solution

The dilemma with DaRT and remote connections is that we cannot in most cases let the users know the password of our local administrator account so what we can do is to start the remote connection as soon as possible when DaRT boots. So here is what you need to do to achieve this:

1. Go through the DaRT Recovery Image wizard and create your DaRT.iso. Then extract this ISO file and copy boot.wim which can be found in the sources folder to C:\DaRT and rename it to winre.wim.

2. Start a cmd.exe with administrator privileges.

3. Create a folder called C:\DaRTmount

4. Run the following command (on one line and with no space between “mount-” and “wim”:

dism /mount-wim /wimfile:C:\DaRT\winre.wim /index:1 /mountdir:C:\DaRTmount

5. From the same command prompt, type “notepad” to start Notepad and then browse to C:\DaRTmount\Windows\System32 and open winpeshl.ini. Make sure that this is entered into the winpeshl.ini and then save the file:

[LaunchApps]
"%windir%\system32\netstart.exe -network -remount"
"cmd /C start %windir%\system32\RemoteRecovery.exe -nomessage"
"%windir%\system32\WaitForConnection.exe"
"%SYSTEMDRIVE%\sources\recovery\recenv.exe"

6. When the file is saved make sure that you have closed notepad and also all instances of Windows Explorer (yes, the following command might fail if you have Explorer windows open) run the following command:

dism /unmount-wim /mountdir:C:\DaRTmount /commit

7. After the image has been saved you need to replace the existing Windows recovery environment with your customized DaRT installation.

8. Start by making sure that you show hidden and operating system files (via Windows Explorer – Organize – Folder and search options – View).

9. Go to C:\Recovery (if you get “access denied”) you need to modify the access control list, add your account or everyone full control to this folder.

10. Now scroll down the folder structure until you reach where winre.wim is located. Now copy your modified winre.wim from C:\DaRT to this location. Remember to set the ACLs back on the recovery folder when you are finished, that is if you modified them.

11. Test by booting the machine and press F8 just before Windows starts loading and you will get “Repair your computer” option. Choose that and see how the Remote Connection is started along with the prompt for local administrator password, giving your users a chance to let you connect and then giving the IT staff enter the password.

12. Done!

HOW TO: Handle user group policy settings in multiple OS environments

This is a very common question and one that I would say all companies migrating to Windows 7 has experienced. The scenario is how do we handle user group policy settings when we have multiple operating systems such as Windows XP and Windows 7 or in the future also introduce Windows 8?

First I strongly recommend that you do not reuse the user configuration for Windows XP for Windows 7. Group policies tend to grow over time and at most customers I have encountered a lot of rubbish in the old configuration. Starting over and migrating only what is needed minimize the risk for problem and makes the configuration slicker and more easy to manage in the long run.

But how do we make sure that users get one configuration when they log in to for instance Windows XP and another configuration when they log in to a Windows 7 or Windows 8 machine? Well, let’s have a look at the options including pros and cons followed by recommendations from the field.

1. Security group filtering

  • Pros:
    – Require no change in OU structure/move of users.
  • Cons:
    – Requires a lot of management and make it hard to administer.

2. Separate users into a new and old OU

  • Pros:
    – Easy to do if you have very few users and no dependencies to other services or applications.
  • Cons:
    – Not a manageable solution in an environment with many users.
    – There are often apps or services that rely on the users being in a certain OU which is making it hard to move users without affecting other services.

3. WMI filters

  • Pros:
    – Keep the users in the OU they are today not affecting other services or apps that rely on users being in a certain OU.
    – A longterm investment in making it easy to introduce new operating system versions.
    – Quick determination (WMI is often known to be real slow but this particular query is not performance intensive).
  • Cons:
    – Need changes for existing environment, i.e. for instance Windows XP user configuration.
    – Could make group policies not being applied due to problems with WMI repository or related services.

4. Loopback processing

  • Pros:
    – Keep the users in the OU they are today not affecting other services or apps that rely on users being in a certain OU.
    – Very reliable solution.
  • Cons:
    – If not Replace mode is used you need to handle current configuration.
    – Might become a mess to troubleshoot and maintain if naming and config is not done consistent and clear.

Recommendations from the field

In my professional opinion the only real alternatives are WMI filters or loopback processing and sometimes I recommend WMI filters for separating user settings depending on what operating system they are logging in to and sometimes I recommend loopback processing. It depends on the environment and needs for the customer. Many times moving the user accounts around is not an alternative but consider that a very good alternative if possible to accomplish.

How do I implement it in my environment?

1. WMI filters

In the Group Policy console you create multiple WMI filters for for instance Windows XP and Windows 7. You then set each WMI filter respectively on each GPO containing user settings for each operating system. NOTE: Always test it out before applying this configuration to your existing environment. Also note that this does not affect performance to any noticeable amount of time.

Windows XP:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "5.2%" AND ProductType ="1"

Windows 7:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.1%" AND ProductType ="1"

Windows 8:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.2%" AND ProductType ="1"

Basically the version is the OS version as we know it and the ProductType=1 means that it is a client operating system.

So you will end with for instance one GPO named “User Configuration – Windows 7” which have the WMI filter for Windows 7 machines set and one GPO named “User Configuration – Windows XP” which have the WMI filter for Windows XP set.

2. Loopback processing

A prerequisite for using loopback processing is that you keep computers in separate OUs, for instance XP computer accounts in one OU and Windows 7 computer accounts in another OU.

You then create GPO objects in the OU for Windows 7 in our example and configure the user settings there. As I think you should always separate Computer and User configuration GPO:s I would say that you in a Computer configuration policy in that same OU set this setting for the user settings to be applied when users log into Windows 7 machines:

Policies – Computer configuration – Administrative templates – System – Group Policy and there set “User Group Policy loopback processing mode” to Replace or Merge, depending on what you want to achieve and how you want to handle your current configuration. Replace mode is recommended as you will have a hard time maintaining and troubleshooting the configuration otherwise.

Done! When users log on to your Windows 7 machines they will get the user settings you have defined in the user configuration GPOs located in the Windows 7 machines OU in our example.

System Locale not set correctly causing SQL Server to fail installation with error “Performance counter registry hive consistency”

Hit an interesting issue when I was about to do a MAP (Microsoft Assessment and Planning Toolkit) scan at a customer. When installing SQL Server Express 2008 R2 I hit a problem  and got the error message “Performance counter registry hive consistency” = FAILED installation.

The problem was that the System Locale was not set properly for my Windows 7 box. Fix was to set it under Region and Language – Administrative tab and there set the system locale and restart the machine. After that the SQL Server installation went fine!