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.


Challenge


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

Preparation

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.


Execution

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




Monday, June 23, 2014

Configuring Chrome and Firefox for Windows Integrated Authentication

Windows Integrated Authentication allows a users' Active Directory credentials to pass through their browser to a web server. Windows Integrated Authentication is enabled by default for Internet Explorer but not Google Chrome or Mozilla Firefox. Users who use the non-Microsoft browsers will receive a pop-up box to enter their Active Directory credentials before continuing to the website. This adds additional steps and complexity for users who are using web based applications. In an effort to make this process as easy as possible for end-users, many IT administrators enable Windows Integrated Authentication for the third party browsers. This can be done with Chrome and Firefox with a few additional steps. This article will show you how to enable Windows Integrated Authentication for Google Chrome and Mozilla Firefox.

Configuring Delegated Security for Mozilla Firefox
To configure Firefox to use Windows Integrated Authentication:
1. Open Firefox.
2. In the address bar type about:config

3. You will receive a security warning. To continue, click I’ll be careful, I promise
4. You will see a list of preferences listed. Find the settings below by browsing through the list or searching for them in the search box. Once you have located each setting, update the value to the following:   

Setting
Value **
network.negotiate-auth.delegation-uris
MyIISServer.domain.com
network.automatic-ntlm-auth.trusted-uris
MyIISServer.domain.com
network.automatic-ntlm-auth.allow-proxies
True
network.negotiate-auth.allow-proxies
True

** MyIISServer.domain.com should be the fully qualified name of your IIS server that you are setting up the Windows Integrated Authentication too.
Negotiate authentication is not supported in versions of Firefox prior to 2006.


Configuring Delegated Security in Google Chrome
You can use three methods to enable Chrome to use Windows Integrated Authentication.Your options are the command line, editing the registry, or using ADMX templates through group policy. If you choose to use the command line or edit the registry, you could use Group Policy Preferences to distribute those changes on a broader scale. Below are the steps for the three methods:

To use the command line to configure Google Chrome:
Start Chrome with the following command:

Chrome.exe --auth-server-whitelist="MYIISSERVER.DOMAIN.COM" --auth-negotiate-delegatewhitelist="MYIISSERVER.DOMAIN.COM" --auth-schemes="digest,ntlm,negotiate"


To modify the registry to configure Google Chrome:
Configure the following registry settings with the corresponding values:
Registry                               
AuthSchemes                           
Data type: String (REG_SZ)
Windows registry location: Software\Policies\Google\Chrome\AuthSchemes
Mac/Linux preference name: AuthSchemes
Supported on: Google Chrome (Linux, Mac, Windows) since version 9
Supported features: Dynamic Policy Refresh: No, Per Profile: No
Description: Specifies which HTTP Authentication schemes are supported by Google Chrome. Possible values are 'basic', 'digest', 'ntlm' and 'negotiate'. Separate multiple values with commas. If this policy is left not set, all four schemes will be used.
Value: "basic,digest,ntlm,negotiate"

AuthServerWhitelist                  
Data type: String (REG_SZ)
Windows registry locationSoftware\Policies\Google\Chrome\AuthServerWhitelist
Mac/Linux preference name: AuthServerWhitelist
Supported on: Google Chrome (Linux, Mac, Windows) since version 9
Supported features: Dynamic Policy Refresh: No, Per Profile: No
Description: Specifies which servers should be whitelisted for integrated authentication. Integrated authentication is only enabled when Google Chrome receives an authentication challenge from a proxy or from a server which is in this permitted list. Separate multiple server names with commas. Wildcards (*) are allowed. If you leave this policy not set Chrome will try to detect if a server is on the Intranet and only then will it respond to IWA requests. If a server is detected as Internet then IWA requests from it will be ignored by Chrome.
Value: "MYIISSERVER.DOMAIN.COM"

AuthNegotiateDelegateWhitelist 
Data type: String (REG_SZ)
Windows registry locationSoftware\Policies\Google\Chrome\AuthNegotiateDelegateWhitelist
Mac/Linux preference name: AuthNegotiateDelegateWhitelist
Supported on: Google Chrome (Linux, Mac, Windows) since version 9
Supported features: Dynamic Policy Refresh: No, Per Profile: No
Description: Servers that Google Chrome may delegate to. Separate multiple server names with commas. Wildcards (*) are allowed. If you leave this policy not set Chrome will not delegate user credentials even if a server is detected as Intranet.
Example Value: ”MYIISSERVER.DOMAIN.COM”

To use ADM/ADMX templates through Group Policy to configure Google Chrome:
1.       Download Zip file of ADM/ADMX templates and documentation from: http://www.chromium.org/administrators/policy-templates.

2.       Add the ADMX template to your central store, if you are using a central store. For more information see the Specops Password Reset Administration Guide.

3. Configure a GPO with your application server DNS host name with Kerberos Delegation Server Whitelist and Authentication Server Whitelist enabled.

Each of these three methods achieve the same results for configuring Google Chrome for Windows Integrated Authentication. The method that is best for you will depend on how your organization is set up.  Personally, I would use the command line or the registry if you are deploying across an enterprise. You can easily distribute a shortcut on the user’s desktop with the command and distribute that with Group Policy preferences. If you choose to use the registry method, that is able to be distributed with Group Policy. 

With a variety of third-party browsers available, many users will receive a pop-up box to enter their Active Directory credentials before continuing to an IIS hosted web application. This leads to additional steps, complexity and confusion for many end-users. By setting up Windows Integrated Authentication into Chrome and Firefox, you will be able to give your users the greatest amount of flexibility for their choice of browser as well as ease of use with your web-based applications.   



Heather Pacan, Product Specialist