Display Computer Information during an OS Deployment

Our CTO and founder Thorbjörn Sjövold came up with this handy little utility for displaying some computer information during the preinstall phase of an OS Deployment.
As Specops Deploy /OS is built on top of standard components such as MDT 2010 Update 1 it's easy for admins to manipulate steps within the task sequences to carry out additional functionality such as adding an email post os install or displaying some handy information during the preinstall phase like so..

Here's how you do it.. 

• Download the sample HTA here and save it to <InstallationDrive>\Specops\Deploy\DeploymentRepository\Scripts directory on your Specops Deploy Image Server.
• On the Specops Deploy /OS Image Server open the Microsoft Deployment Toolkit Deployment Workbench.
• Open a Deployment Share and navigate to the Specops Deployment Respository which resides in  <InstallationDrive>\Specops\Deploy\DeploymentRespository.
• Navigate to the Task Sequences node, right click on the installation Task Sequence that you want to have the computer information dialog in and select Properties.

• Select the Task Sequence tab, open the Preinstall node and select the Report progress step

• Select the add button and under general choose "Run Command Line"

• Set the name to Display Computer Information (by default it says Run Command Line)
• Set the Command line to cmd.exe /c start "" mshta.exe "%SCRIPTROOT%\SpecopsComputerInfo.hta"

• Press OK and close all dialogs and the Deployment Workbench
• Finally open the Specops Deploy /OS Admin tools and select the Image Server and Publish Deployment Repository to have the change pushed out to the Deployment Servers.

• Start your deployment and you should see the computer information displayed during the preinstall phase.

Unable to Start the Specops Deploy Server service

Sometimes when the Specops Deploy Server Service attempts to start you receive an error saying the service is unable to start.  The details of the event log error message are as follows

====
Critical error when starting the service.
Exception is 'System.InvalidOperationException: Custom counters file view is out of memory.
   at System.Diagnostics.SharedPerformanceCounter.CalculateMemory(Int32 oldOffset, Int32 totalSize, Int32& alignmentAdjustment)
   at System.Diagnostics.SharedPerformanceCounter.CreateInstance(CategoryEntry* categoryPointer, Int32 instanceNameHashCode, String instanceName, PerformanceCounterInstanceLifetime lifetime)
   at System.Diagnostics.SharedPerformanceCounter.GetCounter(String counterName, String instanceName, Boolean enableReuse, PerformanceCounterInstanceLifetime lifetime)
   at System.Diagnostics.SharedPerformanceCounter..ctor(String catName, String counterName, String instanceName, PerformanceCounterInstanceLifetime lifetime)
   at System.Diagnostics.PerformanceCounter.Initialize()
   at System.Diagnostics.PerformanceCounter..ctor(String categoryName, String counterName, String instanceName, Boolean readOnly)
   at SpecopsSoft.SpecopsDeploy.Server.ServerPerformanceCounters.SetInstanceValue(Guid instanceName, Int32 instanceValue, DeploymentOperationClientState clientStateToSet)
   at SpecopsSoft.SpecopsDeploy.Server.SpecopsDeployServer.SynchronizePerformanceCounters()
   at SpecopsSoft.SpecopsDeploy.Server.SpecopsDeployServer.Initialize()
   at Specopssoft.GroupPolicy.GpExtensionServerBase.Start()
   at SpecopsSoft.SpecopsDeploy.Server.SpecopsDeployService.OnStart(String[] args)'
====

This error can be caused when .Net hits the cap for the amount of memory it is allowed to allocate to performance counters.

Make the following configuration change on the Specops Deploy Server to increase the amount of memory available for this purpose:

Add the following three lines  within the configuration section of the machine.config file in %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG for x86 based systems or %windir%\Microsoft.NET\Framework64\v2.0.50727\CONFIG for x64 based systems

<system.diagnostics> 
<performanceCounters filemappingsize="1048576" /> 
</system.diagnostics>
</configuration>  - Existing line do not modify

You can set the value as high as 33554432 and the default is 524288. The value represents the maximum amount of memory that the performance counters can use.  Save the file to your desktop as machine.config then manually copy of the existing file in the appropriate folder.

Reboot the Specops Deploy Server in order to apply the change correctly.

soPrincipalExists

I got a problem installing Specops Inventory / Specops Reporting at a cutomer today. Debug Log and Eventlog was comaplaining about soPrincipalExists. This is the exact error message in Eventlog;

System.InvalidOperationException: The stored procedure 'soPrincipalExists' doesn't exist.
   at System.Data.SqlClient.SqlCommand.DeriveParameters()
   at System.Data.SqlClient.SqlCommandBuilder.DeriveParameters(SqlCommand command)
   at SpecopsSoft.Data.SqlHelperParameterCache.DiscoverSpParameterSet(String connectionString, String spName, Boolean includeReturnValueParameter)
   at SpecopsSoft.Data.SqlHelperParameterCache.GetSpParameterSet(String connectionString, String spName, Boolean includeReturnValueParameter)
   at SpecopsSoft.SpecopsInventory.Server.SpecopsInventoryDbAccess.PrincipalExists(SqlTransaction transaction, Guid guid, Int32& principalId)
   at SpecopsSoft.SpecopsInventory.Server.SpecopsInventoryServerWorker.UpdateDatabase(SqlTransaction transaction, Guid principalGuid, String principalName, Boolean isComputerPrincipal, XmlDocument doc, DateTime executionTime)
   at SpecopsSoft.SpecopsInventory.Server.SpecopsInventoryServerWorker.ProcessInventoryResult(String xml)

The solution is to check Permissions in the SQL Server. I had to remove and grant dbOwner access to the Specops Inventory Service Account for Specops3 Database.

Restarted the service and problem solved.

WCF and WIF, Delegation and Kerberos Failure

I recently ran into an issue where a client of ours was trying to implement Version 5.1 of Specops Password Reset. The implementation was "Multi-Tiered" in that the Web Component was on a separate server from the Password Reset Component.

As Specops Password Reset relies on kerberos to identify and authenticate the user during enrollment, we needed to make sure that delegation was working correctly. What ever we tried we could not get this ti work. Normally it is just a case of adding an SPN to the web server account for the URL that the user will be using to access the site, and trusting the web server for delegation (In this particular case we we're also adding it to an IIS 7.0 web farm, but more on that later). But no matter what we tried the page kept reporting that it could not identify the user, the exact error was "The request for the security token could not be satisfied because authentication failed", and when we looked at the security logs on the servers we could see the authentication attempts coming in as Anonymous and using NTLM and not kerberos.

After trawling through a tonne of logs and traces, finally our WCF/WIF guru Janne analysed a Wireshark trace for me and noted that the SPR Server (not the web server) could not locate the UPN of the service account it was running under. We checked this out, but the account matched. We did notice however that this particular UPN name was 33 characters in length, and AD had obviously truncated this down to the 20 character, Pre Win 2000 length in the account properties. We decided to swap the full length name for the truncated one in the sites web.config file, did an IIS reset and VOILA! kerberos sprang from the gates of hell and into life.

Janne is going to mention it to the WCF/WIF team and see if they know about it, hopefully it'll get fixed at some point in the future.

So the lesson here is, if you work in a organisation who's naming convention may force you to generate long user names, don't expect them to always work especially with kerberos delegation. NT4 lives on!!!

Access is denied when importing a OS to Specops Deploy

My colleague Darren James ran into a interesting problem where a customer could not import a OS to Specops Deploy / OS.

Problem: When doing an import of a Windows 7 OS from DVD into Specops Deploy OS. You instantly get "Access is Denied".

Cause: McAffee Antivirus.

Solution: Either disable McAffee Antivirus Realtime Protection while you do the import, or setup exclusions of the DVD Drive and Specops Deploy repository folder.

Failing Specops Deploy package

A customer had a problem with a App Deploy package that's not working.
He says it works fine when executing manually with runas administrator, but it's not working when using Specops Deploy, on a computer target.

I asked him for the package to have a look at it. He was trying to execute a script to change drive letters on a PC.

And Deploy was giving feedback : -2147467259 Unidentified Error

Cannot Deploy Applications via Normal Group Policy Software Installation (GPSI)

I had an issue with a client this week where they could not deploy any application (including our Specops Deploy CSE) via normal Microsoft Windows group policy software installation. This was happening on a Windows 2008 R2 Domain and Windows 7 x86 clients, but I believe it could happen on any mixture of Windows OS and Domains.

Every time group policy ran they get a couple of events in the clients System Log.

Event ID 108 and Event ID 1085 with the following data inside.

Error Code 2147746153
Error Description There is no software installation data object in the Active Directory. 

A manual GPUPDATE would report that a group policy software installation was due but failed, but no further information was given.

Did some googling, not a lot of results, but found that this error might be due to a "corrupt" Default Domain Policy GPO. The physical GPO files are not corrupt and GPOTOOL will not find any errors, but in AD (only viewable with ADSIEDIT.MSC) there will be a GPO that has the Microsoft Application Management CSE GUID ({C6DC5466-785A-11D2-84D0-00C04FB169F7}) specified in it, but that same GPO does not display anything to be installed under the GPO settings in GPMC or GPO Editor.

I checked out their Default Domain Policy, that was fine. I then had to figure out a way of finding if there were any other policies that may had been affected in the same way.

The only way to find out which GPO is causing the issue is to search for the GUID in AD by using LDP. More info on LDP below

http://technet.microsoft.com/en-us/library/cc772839(v=ws.10).aspx

Bind to your local DC with Domain Admin credentials

choose a base DN e.g.

CN=policies,CN=system,DC=domain,DC=com
Choose a filter of

(gPCMachineExtensionNames=*{C6DC5466-785A-11D2-84D0-00C04FB169F7}*)

Choose Subtree for your Scope

This will display a list of GUIDs which relate to the GUID of the GPO's that contain Group Policy Software Installations (in the picture above there is just one result being displayed)

Run GPOTOOL and pipe it to a text file to generate a list of GPO GUIDs and also their friendly names. GPOTOOL download below

http://www.microsoft.com/download/en/details.aspx?id=17657

Check each GPO found by LDP for existing GPSI settings, and make sure they are valid e.g. the share is accessible etc

If you find a GPO that is in list from LDP but does not have any software installation settings displayed in GPMC or GPO editor then this is the corrupt GPO.

NOTE! BE VERY CAREFUL IN ADSIEDIT. You can fatally damage your Active Directory if you delete something you shouldn't! Make sure you have a backup of your DC's and make sure you can recover it. I'd also advise that you make a copy of the contents of gPMachineExtensionNames attribute just in case you delete the wrong bit!

To fix it just open ADSIEDIt, connect to the default naming context.

CN=policies,CN=system,DC=domain,DC=com
right click on the GUID of the corrupt GPO, and select Properties

edit the gPMachineExtensionNames attribute

and remove the Application Management CSE from the long list of GUID's

{C6DC5466-785A-11D2-84D0-00C04FB169F7}

Run GPUPDATE on your client computers and it will run through without error.

Problem Solved.... Carry on with the easy task of installing Specops Deploy!

Thanks for reading, hope it helps someone.

Unsupported Sysprep scenarios

Specops Deploy is using Microsoft Deployment Toolkit, which is using Sysprep to capture a client when doing a new image. There are some scenarios that Microsoft does NOT support when doing sysprep as described in KB: 828287

Here is the most important stuff from that article;

Multicast Optimizations

Multicasting is a great technology when it works. And from my experience doing deployments in quite a lot of different environments in the last couple of years, it seems to work in about 50% of the networks.

This blogpost will be about things you can do to speed up the Multicast transfer.
Here is a quick crash course in Multicasting from cisco if you want to refresh your networking skills.

Owner of a computer as Local Admin

I helped a company last week to setup a solution where the users could request to become local admin of their computers.

Generally I'm against users being local admin. That's XP style ... And nowadays a user usually does not need local admin access. It's possible to get around most of the obstacles.
Local Administrator tend to cause more problems than it helps, and increases the IT Cost as most IT Staff is well aware of.
But, lets face it. There are scenarios were some of the users really do need to be local admin.

How to ... Handle Application Deployment GPOs

A few times per month, I'm being asked if the customer should use one GPO for all their Application Deployments or one GPO's for each deployment?

As with almost everything in life, it depends... And both ways got pros and cons. And of course, there is a middle way, where you have a couple of GPO's with all your deployments in.

I've seen environments where they have had thousands of GPO's in the AD. And where they have totally lost control and don't really know which GPO is linked where and what it contains.
These customers usually tend to lean toward also using one GPO per Deployment.
I think it creates a false feeling of control and a lot of extra administration to do it that way.

First of all, using that many GPO's is usually an old inheritance. Somewhere it got out of control and it's too much work to consolidate the GPO's so they just keep on working like that, adding more and more GPO's.
Using one GPO per Deployment might have been how they have handled Application Deployments with the built in Group Policy Software Installation (GPSI) engine so they could filter the GPO on Security Groups and control which clients got the app.
But it's not needed in Specops Deploy, since we can use Targets inside the GPO. Meaning, a customer can basically link the Specops Deploy Application GPO to the Root of the Domain and handle all Deployments with one GPO. (I wouldn't recommend anyone to really link it to the Root, but rather to the OU's.)

The pros of using multiple GPO's for Deployments is that it's easy to control who the GPO is applied to and it will reduce the risk of corrupted deployments (more on that later).
Also, by using a lot of GPO's and security filtering, it's possible to reduce the number of GPOs (and targets) the client has to process.
The cons is that it causes a lot of administration. It's hard to get a good overview of your deployments.
And when you want to look at the Feedback, you have to open multiple GPOs so see it, takes time.

One GPO to Rule them all ... This is usually what I recommend. It gives you the full power of Specops Deploy. You have one place where you work with your Deployments, you can reuse your Targets and don't have to create new ones in each GPO. It's easy to see the Deployment Feedback.
And from my point of view, it gives best control.

Using just one GPO's when you have several hundred targets and thousands deployments in one GPO will cause all your clients in the environment to process all those Targets each time the computer boots and also each GPO.
Which in our testing is still not slower than dividing the settings into multiple GPO's. Because, loading a new GPO is generally slower than processing our targets.




But, having one GPO can cause an administration problem. As you know, with GPO's its the last write who wins. So if two or more admins are editing the same Specops Deploy GPO, it can become corrupted. Having more than one GPO will reduce that risk.
If you have a license for it, using Microsoft Advanced Group Policy Management (AGPM) will make it possible to have just one admin working on a GPO at a time. So the corruption problem will not happen.


Alternatively using 2-4 GPOs will also reduce the risk of two admins working on the same GPO at the same time. For example, divide the apps into 4 GPO's Microsoft, Adobe, Line of Business, Other

BiosConfig Tool

This is hopefully old news for our existing and longtime customers, but might be useful for some of the new ones.

If you have not been using MDT, RIS, SCCM or any other similar deployment solution in the past, there is a big risk that your clients are not configured to PXE Boot. Running around manually to hundreds or thousands of clients to reconfigure BIOS is not really an option.

There are luckily multiple ways to solve that. You can either check with your hardware manufacturer if they have a tool to change boot order via a script or remotely, or you can use the BiosConfig.exe tool shipped with Specops Deploy.

There is a folder on your server called; C:\Program Files\Specopssoft\Specops Deploy\Admin Tools OS\Bios Config Tools which contains the Biosconfig.exe and Biosconfig.ini (configuration file). It support HP, Fujitsu and Dell computers. Unfortunately not Lenovo at this time.

I will be running this on my Dell Laptop and show how it behaves.
First, the syntax;

C:\BIOSCONF>BiosConfig.exe -?
General:
  -h [ --help ]              product help message
  -v [ --verbose ]           Display verbose error messages
  -f [ --force ]             Force command execution even if versions match
  -s [ --showComputerInfo ]  Display computer make and model

It's quite straight forward. Verbose is only needed for troubleshoting and the force would be used to make it execute always. Else it's checking if it has already been run since the config file was updated last time.
And -S will give you some details about the client.

C:\BIOSCONF>BiosConfig.exe -s
Dell Inc. Latitude E6420
Manufacturer:      Dell Inc.
Name:              Default System BIOS
SMBIOSBIOSVersion: A07
Version:           DELL   - 6222004
Serial:            D4754Q1

To run the tool normally, just execute it without any command line switches.

C:\BIOSCONF>BiosConfig.exe
There is no section for the current computer in BiosConfig.ini
Dell Inc. Latitude E6420

That means, that we have not enabled the Dell section in the biosconf.ini file.
Open it with notepad and make it look like this (notice the missing ; infront of some of the lines);


[General]
;; Increment version to run the actions again. Otherwise, the actions below are only executed once.
Version=1

[MakeModel]
;Hewlett-Packard*=HP
Dell*=Dell
;Fujitsu*=Fujitsu

;; Use brackets around all values below, i.e. Key=[Value]

;; For more information see:
;; HP Client Management Interface (WMI)
;; http://www.hp.com/go/hpcmi
;; For examples see:
;; http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1261047544829+28353475&threadId=1208628
;; Extract HPCMIProviders.msi from downloaded setup.exe
[HP]
;RunExe=[%windir%\system32\msiexec.exe /i "%BiosConfigDir%HP\HPCMIProviders.msi" /qn REINSTALLMODE=vomus REINSTALL=ALL ]
;HPWOL=[on]
;HPPXE=[on]

;; For more information see:
;; http://support.ts.fujitsu.com/download/Showdescription.asp?ID=1043393
;; Use the BIOSSET.EXE file
[Fujitsu]
;RunExe1=[fujitsu\biosset.exe /BOOTORDER=1LAN /PWD=%SpecopsBIOSPassword%]
;RunExe2=[fujitsu\biosset.exe /WOL=ON /PWD=%SpecopsBIOSPassword%]

;; For more information see:
;; http://www.dell.com/content/topics/global.aspx/sitelets/solutions/management/client_software?c=us&l=en&cs=555
;; Extract x86\setup.exe from for example DELL_OPENMANAGE-CLIENT-INSTR_A00_R214518.exe
;; Extract x64\setup.exe from for example DELL_OPENMANAGE-CLIENT-INSTR_A00_R214519.exe
[Dell]
;RunExeX86=[dell\x86\setup.exe /s /v/qn]
;RunExeX64=[dell\x64\setup.exe /s /v/qn]
DellWmi=[<Dell_WmiClass>.<Property>=<value>]
DellPXE=[on]
DellWOL=[on]
DellForcePXEOnNextReboot=[on]

;; For more information see:
;; http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-41472
[Lenovo]


[BiosNetworkBootDevices]
Network*



Running the tool again, gives us this;

C:\BIOSCONF>BiosConfig.exe
Dell WMI string was incorrect.
<Dell_WmiClass>.<Property>=<value>
DellWmi=[<Dell_WmiClass>.<Property>=<value>]

It's because the Dell WMI classes has not been installed yet, so the tool does not know how to communicate with the BIOS.

There are two options here. You can either let the tool install the WMI Classes at that time. Or as I prefer to do, deploy the WMI Classes via Specops Deploy / App in advance which gives me more control.

You can use the links in the INI files to find and download the OpenManage Client. I've noticed that I've had to download and install different versions of the Client for various models in the past. For example an older version for old Laptops and a new version for the new models.

So, create a package that deploys the OpenClient (msi package) to your clients with a "Make and Model filter.
And then create a package that runs biosconfig.exe on the same clients to automatically configure them for PXE and Wake On Lan.


If your clients have a BIOS Password, then set the password in %SpecopsBIOSPassword% before executing the tool. That password will then be used to access and modify bios.

Multiple image servers error

Problem: When starting Specops Deploy / OS Admin Tools you are getting an error message;
Multiple image servers (servername1, servername2) found.
Specify the name of the server to use on the registry key
PreferedImageServer at HKEY_CURRENT_USER\SOFTWARE\Specopssoft\Specops Deploy\Admin Tools OS

Cause: Specops Deploy / OS Image Server has been installed on a previous server and not been uninstalled correctly. 

Solution: Open Active Directory Users & Computers, locate the old server and delete the "Specops Deploy Image Server" child object from that server.

Then restart the Admin Tool. 

Workaround: Specify the servername in the mentioned registry key.

Self Service Portal - ManagedBy Feature - Preview

The Specops Self Service Portal makes it possible for the user to request and deploy applications or other services to users and computers without contacting the helpdesk.

But for a user to be able to request something to that users PC, the user has to be the "owner" of that client. The reason is that we don't want to risk that Sylvester is ordering applications to Arnolds PC, right?