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


Wednesday, June 18, 2014

Scheduling a Lab Refresh

You manage Lab machines and want to ensure that they’re rebuilt on a regular basis. Applying a fresh image can benefit you in many ways; lowers support costs, ensures consistency, and sets up learning environments for success. Whatever the reason, if the process is simple and repeatable, you will benefit.

Recently, in a discussion with Specops Deploy / OS administrators, this scenario has come up. The process to create a ‘set-it-and-forget-it’ environments is simple, yet very interesting.

Step 1 – preparations and assumptions

To provide simple guidance, we must start with a few assumptions. 
  1. Specops Deploy / OS is setup
  2. Policy is applied to computers
  3. Machines are domain joined and turned on
  4. You have access to the machine where the administration tools are installed

Step 2 – get computer names

There are many ways to get the computer names of the lab machines. One way is to create a CSV that contains a list of the computer names. The column header in the file must say ‘computernames’. Each line should contain the name of a computer in the lab you intend to refresh. Once you have the .csv file, you can use the ‘Import-CSV’ cmdlet to get those names into the PowerShell pipeline.


Another way to get the names of the lab computers is to use one of the AD cmdlets. You can use the Get-ADComputer cmdlet and provide a filter to return only those computers that are lab machines to be refreshed. 

The problem with the Get-ADComputer cmdlet is that it returns data that isn’t quite compatible with target cmldet and the conversion requires a bit more PowerShell than we want to deal with today. In this example, we will use the CSV and we will pipe that into our next cmdlet.

Step 3 – build script

We will use a small and relatively basic script for this scenario that highlights some interesting PowerShell concepts, and provides an opportunity to discuss some PowerShell basics.

This script will take the computer names from the CSV and use them to target the Reinstall-SDComputer cmdlet. Reinstall-SDComputer is provided as part of the Specops Deploy / OS Admin Tools. The module ‘specopsdeploy’ contains this cmdlet, along with other cmdlets, and must be present on the machine where the script runs.

I like to use the PowerShell ISE which allows you to easily develop your script while you test the syntax of particular cmdlets in the console. You can also use all the help functionality built into the ISE such as the color-coded script editor and console, copy/paste functionality, intellisense and the ‘Commands’ window.

Enter Show-Command in the console and the command window will display. You can also anchor it to the side of the ISE if you have the space for it. Enter ‘Reinstall’ into the ‘Name’ field and select ‘Reinstall-SDComputer’.


Select the PXE tab and enter the information you have. Once complete, click copy at the bottom of the screen. Paste the command into the script window of the ISE.


The above example has a bit more going on but it demonstrates the point here.

At the beginning of the script we use ‘Import-CSV’ cmdlet to grab the computer names out of the file you created. Those will be piped directly into the ‘Reinstall-SDComputer’ cmdlet. The | character is the pipe. It will take the objects in the PowerShell pipeline one at a time and feed them to the ‘Reinstall-SDComputer’ cmdlet.

The script looks like this and should be saved as a .ps1 file.

Step 4 - create scheduled task

There are many settings you can configure in the schedule task. Below are some of the basics that are important to cover:
  1. PowerShell.exe is the action being scheduled
  2. The -Command switch of Powershell.Exe points to the .ps1 file created above, and the .ps1 file points to the .csv that has your list of computers 
  3. Trigger (schedule) must be 'enabled'
  4. Set your schedule to meet your intent (for example ‘second Friday of the month at 10:00PM)

Summary

Specops Deploy / OS provides the functionality IT administrators need to simply manage their OS deployments. Providing capabilities as PowerShell cmdlets allows administrators to think beyond the UI and come up with creative ways to use the technology to meet their business needs. Scheduling the refresh of labs is a great example of extending the capabilities into an automated solution.


Kevin Sullivan, Director of Sales Engineering

Monday, June 9, 2014

Specops USB Boot Solution

Last week I was helping a customer who has a small branch office without its own server. When they wanted to reinstall a computer, they used to bring the computer to the head office because of the poor broadband connection between the offices.

The problem was solved with a cheap network attached storage (NAS) and a little creativity, which resulted in the Specops USB Boot Solution. This guide describes how you can easily create a bootable USB memory stick with the company’s WinPe configured to deploy the right image from a local NAS instead of deploying it over the company’s site-to-site VPN.

Mikael Ingelin, Product Specialist