The Microsoft Deployment Toolkit (MDT) brings a lot of functionality to operating system deployment (OSD) as I’m sure many of you are aware. One of the best features is the ability to incorporate the DaRT tools into the MDT boot WIM. This allows for deployment administrators to remotely connect to a device during OSD. This can be extremely useful in a situation where the device is not local to the admin.
Johan Arwidmark has a great post on how to integrate the tools into the MDT environment with ConfigMgr.
One of the issues with the default DaRT configuration is that the remote connections use a dynamic RPC port instead of a specific port during OSD. It is possible to lock down the port when using DaRT in its fully fledged mode however locking it down to a specific port during the OSD phase is not easy.
I’ve recently been working at a customer who have VERY strict firewall policies in place and would not allow dynamic RPC ports to be open from the ConfigMgr Primary Site Server VLAN to the client device VLAN. This led me to investigate how to lock the port used by DaRT during OSD for remote connections.
After trying several different options, including adding a customised DartConfig.dat file to the base Toolsx86.cab file, I was almost at the point of giving up, I didn’t.
Using the DaRT Recovery Image Wizard I created a DaRT image for Windows 8.1 Update and on the Remote Connection tab I enabled the option to Allow Remote Connections and specified a port to use, in this case 3389 as this was what the customer wanted to use:
During the process I ticked the option to edit the image before the WIM was created:
I then opened the location where the WIM contents were stored and navigated to the Windows\System32 folder to extract the customised DartConfig.dat file:
This file was then copied to a new folder where I’d created a folder structure Windows\System32:
I then finish the DaRT Recovery Image Wizard and started to create a new boot image in ConfigMgr using the “Create Boot Image using MDT” option. During the creation wizard I ticked the “Add extra files to the new boot image” option and pointed to the UNC path folder for the folder I had created above:
This created the boot image and crucially overwrote the default DartConfig.dat file with the one I created earlier. This meant that for all Task Sequences using this boot image the customer would be able to connect to the device using the DaRT Remote Control option in MDT using port 3389 at all times.
One great feature of System Center Configuration Manager 2012 (ConfigMgr) is the new compliance settings and configuration baselines. In ConfigMgr 2007 this was known as Desired Configuration Management.
In ConfigMgr 2012 Microsoft really raised their game and now allow for automated remediation, which I primarily use for registry settings. How annoying is it when you configure an application to not self update when you install an update (probably via ConfigMgr with System Center Updates Publisher) and it resets the settings and merrily checks for updates – usually leading to calls to the Service Desk along the lines of “My computer is telling me there is an update to application X but it won’t let me install it”?
This is where the awesome compliance setting remediation comes in – it can detect a change, and if instructed to do so in the compliance setting, change the value to what YOU have told it to be, not what the application developer wants it to be.
Group Policy Objects
Group Policy Objects (GPOs) give you ultimate control over a domain joined client (be that server or desktop). If you’ve got the Microsoft Desktop Optimisation Pack (MDOP) then you’ve got access to Microsoft’s Advanced Group Policy Management (AGPM) tools – which are fantastic. MDOP is well worth and it’s cheap (yes that is cheap and Microsoft in the same sentence). It allows you to log change to GPOs, do offline testing and loads more. But what if the left hand doesn’t know what the right hand is doing?
If someone authors a change to a GPO that could potentially change something fundamental, for example changes the Remote Desktop firewall settings, how can you monitor that in ConfigMgr?
Enter Microsoft’s Security Compliance Manager (SCM). You’re probably thinking “What the <insert expletive here>!” Bear with me…
Microsoft’s Security Compliance Manager
SCM is a free Solution Accelerator (of which there are many) from Microsoft that can guide you in deploying GPOs that can help secure your Windows servers and desktops with best practise guidance, documentation galore, and best of all the ability to export CAB files for use in ConfigMgr.
In SCM you can import your existing GPOs and from there you can compare them to Microsoft’s guidance. In addition you can export them to a CAB file for use in ConfigMgr. Big deal? In my opinion – YES! You don’t have to use the comparison aspect, you can just use it as a conduit for the next stage.
In the ConfigMgr console you can import the CAB file in to the compliance settings workspace – this in turn generates an array of compliance settings for you. When you dig a little deeper into these settings you find it uses scripts to check compliance, no auto remediation available here but does a good job of checking settings.
What about just opening the raw ADMX files to find the registry settings?
Rather you than me!
If your GPOs that only contain a few settings you can open the parent ADMX file, find the registry strings and use those for remediation if you want… I don’t know about your environment but that would be a boat load of work for me!
So where’s the benefit?
If you’ve got these settings imported in ConfigMgr you can see when the deployed baselines move away from their GPO settings, this can immediately alert you to one of two things:
- An update, whether that be from Microsoft or another company (remember you can control quite a lot of applications via GPOs, not just Microsoft’s – Google Chrome anyone?), may have changed a value you configured in a GPO
- Or more likely, someone has changed something and not let you know. Now if you’re using AGPM you’ll be able to find the individual and have a little chat…
This is not a catch all. If someone deploys a new setting via a GPO (one that isn’t covered by a compliance setting imported via SCM) you won’t know about it. Communication is key here, make sure left hand knows what the right is doing.
I’d advise you to take a look at the free Solution Accelerators from Microsoft, of which Microsoft Deployment Toolkit (MDT) is one – which I’ve used for years and is amazing for highly configurable desktop deployments. SCM is great tool to see what Microsoft recommend you do with your infrastructure, Windows is now quite secure out of the box but if you want to you can harden it much more. Best of all it tells you what you need to do, where you need to do it and most importantly why!
Just remember that most registry changes require a reboot to take effect. Just because you remediate a setting it doesn’t necessarily mean the setting is in effect – look at TechNet and do your research.