Thursday, December 18, 2014

Setting up a lab

There are so many good reasons to have a lab available. There are very few reasons to not. IT organizations are constantly testing new releases, configurations, and widgets that need to be rolled out. They need to evaluate software and solutions that they want to implement in a production environment. With Windows 8+ and the latest versions of Hyper-V, there is no good reason to not have a lab to use.

With that said, managing the lab in Hyper-V is very easy and to be honest, quite fun. If you are a VMWare shop, that is great. Either way there are some simple techniques and best practices that can be super helpful.

This video walks through some thoughts and ideas on how to manage your lab, how to setup the core environment, and prepare for testing. We’ll try to follow up with additional content related to evaluating Specops solutions, but first things first…


Thursday, September 11, 2014

Orphaned Deployments

Orphaned Deployments

I have been known to say “Group Policy comes without a This may be a career limiting configuration change you are about to make, are you sure!? message.” You can do a lot of things with GP that can cause a ripple effect that you are not prepared for so always be careful, test, then re-test.

With that said, it is also a very predictable system and at Specops we continue to leverage that great predictable system with our solutions.

Recently a Specops Deploy Customer un-linked their SD/Application GPO from an OU. What happens in this scenario?

Managed vs. Orphaned

When an administrator adds a package to their Specops Deploy App GPO they configure that package to behave a certain way. The configured behavior is mostly related to pre-install commands, post-install commands, uninstall behavior and more. The package by itself does not do anything. In order to get a package to a user/computer you create a deployment.

A Deployment can be configured to define additional behavior related to the actual installation of the package. For example an administrator can configure a deployment to ‘Uninstall the package if the deployment falls “Out of the Scope of Management.”’

When a deployment is targeting a computer those deployment(s) will be enacted on that computer and the packages in those deployments will be installed. The deployments will be referenced as ‘Managed Deployments’.

SD Administrators can take a look at managed deployments on client systems in a few different ways. I like to use PowerShell.

PS C:\> Get-Item ‘HKLM:\SOFTWARE\Specopssoft\Specops Deploy\Client Side Extension\Managed Deployments\System\*’

The above PowerShell command will display all managed deployments on that client for you to review.

If a managed deployment disappears, an administrator deletes a link, a user can’t process the GPO due to a group membership change, or any other reason, the deployment may go to ‘Orphaned Deployments’.

PS C:\> Get-Item ‘HKLM:\SOFTWARE\Specopssoft\Specops Deploy\Client Side Extension\Orphaned Deployments\System\*’

This means that there is software still on the client system that is no longer managed by the Specops Deploy Application.

This most likely does not cause an issue for administrators, but if mistakes are made, and GPOs are unlinked and deployments are orphaned, when the problem is resolved those applications may want to re-install themselves. That may not be great.

How to Recover From a Mistake

There is a simple way to resolve the issue if an Administrator mistakenly unlinks a GPO. The Managed vs. Orphaned deployments are stored in the Registry on the client as you can see from the above PowerShell commands. Now they just have to move. So, instead of ‘Get-Item’ we can use ‘Move-Item’.

PS C:> Move-Item ‘HKLM:\SOFTWARE\Specopssoft\Specops Deploy\Client Side Extension\Orphaned Deployments\System\*’ –Destination ‘HKLM:\SOFTWARE\Specopssoft\Specops Deploy\client Side Extension\Managed Deployments\System’

Relink the GPO and you should be good to go. As with everything make sure you test out this procedure in a lab. PowerShell is incredibly powerful so be careful. Fat fingers count.


Want to take this to a new level? Get computer names from a text file or from AD itself and run move-item from that list. Some complex scenarios can be solved simply if you take the time to learn the PowerShell option.

Kevin Sullivan, Director of Sales Engineering

Tuesday, August 19, 2014

Deleting Orphaned Deployments

This may not be the best title for this post. Deleting Orphaned Deployments may be the solution, but it is surely not the problem. The technique described here is something that you can use in other situations where an XML file is involved. The scenario that drove the writing of this post is, of course, specific to Specops Deploy.

The Problem

A strange crash in the Specops Deploy Application Snap-in: An administrator will open the GPMC, find the desired GPO, open the GPO in the editor, navigate to the Specops Deploy Application snap-in, look at deployments, and suddenly the console crashes. A console crash is rare. This scenario is also rare, and it occurs if an Admin ‘deletes’ a package that is referenced in a deployment. The issue can be resolved, but it introduces a very interesting troubleshooting opportunity: How can you fix the deployment if you can’t look at it in the editor?

Specops Deploy Application stores all of the deployment information in the GPO in SYSVOL. The data is stored in an XML file called ‘Deployments.xml’. If you manually edit this file, and delete the corrupt ‘Deployment,’ you are done. This obviously is not a great move. It is ripe for errors and not a good plan of attack.

The Solution

The solution here, and in reality the solution for many such problems is automation. The idea is to remove the opportunity for errors and create a process where you surgically achieve exactly what you want. Here we will call on PowerShell to help us out. One of my colleagues shared a technique to deal with XML files and it is really great. It is actually quite simple.
  1.  Use the Get-Content cmdlet to retrieve the xml file
  2. Shove that file into a variable that is specifically cast as an XML file
  3. The document is now available as an object that can be manipulated as you need

An Example


OK, so here we go. Many assumptions are made here and keep an eye on upcoming posts to walk through additional techniques to help. This post is about the last step, cleaning up an orphaned or corrupt deployment. In my example I have a single GPO with two deployments. Imagine one of these deployments, ‘WinZip 7’, is corrupt.

I have found that this deployment has a unique ID that I will need. I can get this information through PowerShell. Ignore the cmdlets here, they are a topic for other posts. But I use the Specops Deploy Application cmdlets to get the information I need.

Specops Deploy Application - Packages
The deployment has important data that I will need, and the GPO itself has some important information as well.

 Specops Deploy Application - Deployment

Specops Deploy Application – GPO
Now, I have all the information I need to find and correct my issue.


Now to the real meat of the solution. The Get-Content cmdlet will be the way we get to this information. We will throw the file into a variable that we can manipulate. Here is the command without references to my specific test environment and test GPO.
PS C:\> [XML]$x = Get-Content “\\dc1\SYSVOL\<domainName>\ Policies\<GUID of GPO>\Machine\SpecopsDeploy\Deployments.xml”

Execute the above command then take a look at $x. It is an object ready to be used.
NOTE: Use the PowerShell ISE. The ISE provides a lot of additional capabilities that will help navigate, learn and execute on some of the tasks you are attempting. The Intellisense capability of the ISE is worth the price of admission. Once you learn how to leverage it you won’t be able to live without it.

If you type $x. on the command line you will see a list of all of the properties and methods that can be called on here.

If you choose Deployments and add ‘.’ you will see additional properties/methods.

If you play around with this technique you will begin to see how valuable this can be. For this example you want to look at $x.deployments.deployment.

For this GPO there are only the two ‘Deployments’. We only want the one for ‘WinZip 7’. This takes us back to where we found the deployment ID, Package ID etc. In this case we will only need the PackageID attribute associated with ‘WinZip 7’.  

It is all coming together. At this point we have the ‘Deployments.xml’ file in the $x variable. We know the ‘Deployment ID’ is the GUID in the above image. We will create another variable to point to that specific Deployment.

This is a bit of a leap so let’s make sure we are all on the same page.
  1.  Deployments.xml file is stored in a variable, $x
  2. The specific deployment we are targeting is stored in a variable, $s
  3.  The XML object has a method called ‘RemoveChild’ that takes the GUID of the child element to delete. We pass that to the ‘RemoveChild’ method by way of the $s variable.
  4. Then we call the ‘save’ method on $x

Done! Now if I look at Get-SDDeployment ‘WinZip 7’ is gone. 

I can now open the GPO and navigate to Specops Deploy Application and my corrupt GPO is no longer a problem.

Stay tuned for more PowerShell related posts.

Kevin Sullivan, Director of Sales Engineering

Wednesday, July 9, 2014

Multiple Drives Causes a Deployment Error

My colleague Johan had lent his tablet to Mikael, another fellow Product Specialist, to evaluate for a few days.  When Mikael started to deploy Windows 8 to the tablet with Specops Deploy, he got the following error:  Failure (5456): Unable to determine the Destination Disk, Partition, and/or Drive

After some searching, they discovered that if you have multiple partitions or disks in a machine, MDT may be unable to determine where to install the operating system.  MDT is one of the base technologies that Specops Deploy/OS uses to deliver the operating systems to client machines.  In this particular situation, an SD card in the tablet was preventing MDT from determining which disk to install the operating system on.  We did some further testing to try to reproduce the error in another environment.  We were able to replicate this situation on a UEFI machine with two disks.  

There is a simple fix to direct MDT to the disk to install the operating system on.  You will need to go into the Deployment Workbench of MDT and add a variable to the task sequence.   To do this, you will need to attach the Deployment Share to your Deployment Repository to make the changes.  In case you are not familiar with using the Deployment Workbench, here are the detailed steps for connecting to the Deployment Repository and applying the fix:

  1. Go into the Microsoft Deployment Toolkit’s Deployment Workbench.
  2. Right click on Deployment Share and select Open Deployment Share.
  3. Browse to your Deployment Repository.
  4. Select OK, then click on Next, Next and then Finish.
  5. Click on Task Sequences.
  6. On the right side of the screen, right click on the image that you are using and select Properties.
  7. Select the Task Sequences tab.
  8. Expand Preinstall.
  9. Expand New Computer Only.
  10. Click on Format and Partition Disk.
  11. On the lower right side of the screen, highlight OSDisk (Primary) and then click partition properties (which is the middle button on the upper right side of the volume box).  Please see the highlights in the illustration below
  12. Type OSDisk into the Variable box in the bottom.
  13. Click OK.
  14. On the Task Sequence tab, expand the Install folder then select Install Operating System
  15. On the right side under “Select the location where you want to apply the operating system” choose Logical Drive Letter Stored in a Variable from the drop down menu.
  16. Type OSDisk in the variable box.  Select OK.  Please see the illustration below.  

You may exit out of the Deployment Workbench.  Make sure to go into your Specops Deploy/OS Admin console and publish your deployment repository so the changes will be replicated to your deployment shares.  You can also do this by running Publish-SDRepository from an elevate PowerShell prompt.  You can now reboot your client machine and your operating system will install now.

We have discovered that under certain circumstances multiple hard disks or partitions can cause MDT to have an error when it is unsure of where to install the operating system.  The two scenarios that my colleagues and I have tested were a tablet with an SD card inserted into it and a UEFI machine with two hard disks.  There may also be other situations where this happens that we have not come across yet.  By setting up your task sequence in MDT to use the OSDisk variable for the operating system installation location, instead of having it set to a specific disk (which is the default in MDT), you can easily remedy the situation.    

Heather Pacan, Product Specialist

Monday, June 30, 2014

Gpupdate Prof: Read Remote Registry

Gpupdate Professional is a remote management tool that allows a desktop administrator to manage his or her desktop environment from a single location. You essentially get a remote administration center for your client machines through a menu extension in Active Directory Users and Computers. I have been working on a series of blog posts highlighting some of the commands and practical uses for them in your environments. If you haven’t read my articles on the Remote Assistance command or Start Explorer and Run Remote Executable commands, please take a look. I am continuing the series with the Read Remote Registry Command.  This command allows you to read a registry value on a remote machine(s). 

To use this command you will need to make sure the Remote Administration Exception is enabled in the windows firewall and the Remote Registry service is started. The Remote Administration Exception can be enabled by running the following from a command prompt:

 netsh firewall set service type = remoteadmin mode = mode

You can also enable the Remote Administration Exception through group policy:

The Remote Registry service can also be started through Group Policy:

For an example of how to use the Read Remote Registry command, I would like to be able to see which versions of Internet Explorer my client computers are running.  That information is located in the registry on the client machines at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Version

To run the command against all of the computers in a particular OU, you will need to launch Gpupdate Professional on the OU in Active Directory Users and Computers.
  1. Locate the OU in Active Directory Users and Computers that you want to retrieve the registry information from.
  2. Right click on the OU.
  3. Select Specops Gpupdate Professional
  4. Select Read Remote Registry
  5. Type in the full path of the registry key for the value that you are looking for.
  6. Fill in the name of the registry value that you are looking for.
  7. If you want to search all of the sub-OUs select Recurse Target Container
  8. Click Next
  9. Click Execute

You will then see the results displayed in the Gpupdate Professional display window.

Read Remote Registry is a quick and simple remote way a desktop administrators can gather a piece of information about their client machines. My example is only one of many ways this command could be used if you are not using an inventory reporting tool such as Specops Inventory. When troubleshooting remotely, this type of information could be valuable to lead to the resolution of your customer’s support problem. Gpupdate Professional puts you in control of your client machines with a few clicks of the mouse.  Stay tuned for the next article in my series on Gpupdate Professional!

Happy deployments!

Heather Pacan, Product Specialist