Wednesday, February 29, 2012

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.

Thursday, February 23, 2012

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!!!

Tuesday, February 21, 2012

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.


Monday, February 20, 2012

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


Friday, February 17, 2012

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


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

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;

Thursday, February 16, 2012

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.


Wednesday, February 15, 2012

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.

Tuesday, February 14, 2012

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



Monday, February 13, 2012

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.

Friday, February 10, 2012

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.

Thursday, February 9, 2012

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?

Wednesday, February 8, 2012

Self Service Portal - Preview

We have listened to our customers and are soon shipping Specops Self Service Portal. It's a portal where the user can request applications without contacting the helpdesk, with a built-in workflow for approval of the requests when needed.

The user is using the Self Service Portal (SSP) and can see all the applications that user has access to request. As you can see, Windows 8 required approval. The other apps will be installed at once.


The user is requesting Windows 8 and will then have to specify which computer he would like to have it installed on. And makes it possible to type a message to the approving manager.


A user can only request applications to a PC he is "owner of" (we use the ManagedBy attribute in AD), which can be populated automatically by Specops (more info on that tomorrow).

All approving managers for that Unit gets an email notifying him that there is a pending request.


The manager can then Approve or Decline the request.


As soon as the request is approved, a remote GPUpdate will be triggered on the client starting the installation within seconds. And of course, if the application is free (no approval needed) the installation will also start at once.
No more delays for the users, waiting for helpdesk to approve the request!

I showed in yesterdays post a screenshot showing how a user can request (if allowed) a reinstallation of the PC, which will of course also reinstall all applications according to the Specops Deploy policies.



Release is scheduled within the next few weeks. 
Contact your Sales contact at Specops for license and price information.

Tuesday, February 7, 2012

SelfDeploy Tool

One of our customers wanted a solution where their users could start a migration from Windows XP to Windows 7 from within windows, and without being Local Administrator or contacting helpdesk. 

Our developers created this tool SpecopsDeployOsSelfService.
It's not a Self Service Portal, it's just a .exe file the user can execute locally on the PC which will talk to a server component and trigger a reinstall of the PC.

The client has this syntax;

C:\temp\SelfDeploy\SpecopsDeployOsSelfService\DeployReinstallOs>DeployReinstallOs.exe /?
Initiates an reinstallation of the local computer
DeployReinstallOs [/Silent] [/Reboot] [/NoEndPrompt] [/NoConfirm] [/?]

  /Silent               Presents no output to the end user, but unless /NoConfirm is also passed an confirmation question will still be displayed
  /Reboot               Performs a reboot after the computer has been configured for an reinstallation
  /NoEndPrompt  No message and question to exit will be shown after processing
  /NoConfirm            The operating system will be configured for reinstallation without user input
  /?                            Displays this help text
Press Any Key to continue...

You can then create any kind of UI to the application, for example a HTA that shows the user some info and a confirmation box.

To install the server service. Extract the SpecopsDeploySelfServiceServer.zip to a folder on your server, for example into c:\program files\specops\specops deploy\selfdeploy\

Then run this command;
"C:\Windows\Microsoft.NET\Framework64\v2.0.50727\installutil" –i "c:\program files\specops\specops deploy\selfdeploy\SpecopsDeploySelfServiceServer.exe"

Verify in services.msc that the service has been installed and is running.
There should also be a new registry key here: HKEY_LOCAL_MACHINE\SOFTWARE\Specopssoft\Specops Deploy\Deployment Self Service
You can enable Debug logging by using Debug = 1
DisableClientLookup = 1 will not perform a reverse lookup.

You should now be able to trigger a reinstall from the client.
By the way, it will also be possible to do this "out of the box" from the "Specops Self Service Portal" without using the above solution.

The description says it can take some time until the reinstall is
starting. We initiate a start at once via a remote command, but if
there is no access, it will be triggered at next gpupdate.

The user will be able to trigger a reinstallation of any PC that the user is "owner of"....



Monday, February 6, 2012

Deploying Hotfixes with Deploy?

I had a need to deploy this fix: Unexpectedly slow startup or logon process in Windows Server 2008 R2 or in Windows 7 in our production environment today.

Microsoft does not support deploying hotfixes with WSUS, which gave me a great opporutnity to do it with Specops Deploy and also share how it's done in less than 5 minutes.

I downloaded the fixes, extracted them and put them on a DFS Share (with replication to our other sites) separated into x86 and x64 folders.
Then created a .bat file in each folder (x86 and x64).

@Echo off
REM For X86
%windir%\system32\wusa.exe "%SpecopsDeployExecuteDir%\Windows6.1-KB2617858-x86.msu" /quiet /norestart

@Echo off
REM For x64
%windir%\system32\wusa.exe "%SpecopsDeployExecuteDir%\Windows6.1-KB2617858-x64.msu" /quiet /norestart

I created two Packages in Deploy.
And two targets like this, since this will be fixed in SP2 for Windows 7 and Server 2008 R2, i just want it to be applied for now.




The target says, install the package on "Windows 7 and Windows Server 2008 R2 with No Service Pack or Service Pack 1, and running x64".

Then create a deployment.
Done!

The Hotfix will be deployed and installed on all your clients and servers within the next 2 hours.
And if you are in a hurry, just trigger a remote GPUPDATE with for example Specops Gpupdate Pro.


WDS Multicast Configuration

When I'm doing a new Specops OS Deploy installation at a customer I'm always asking if they will be using Multicast and if they have it enabled/configured in the network.
And I'm also recommending our customers to use Windows Server 2008 R2 on the Deployment Servers, due to enhanced functionality compared to previous versions of Windows Server. 

Multicast makes it possible to utilize the network better when deploying multiple clients because the server is sending one stream of data, which is then received by all clients.
Instead of each client downloading one stream of data each.
So, 10 client's downloading one 7GB image, is still ~7-14GB of data with Multicast.
While 10 client's downloading the same 7GB image with normal unicast is 70GB of data in your network.

If they intend to use Multicast and have it configured I'm usually configuring WDS to utilize 2 or 3 Multicast Streams instead of the default one stream.

The reason is that Multicast will adjust the speed to the slowest client in the stream, or else that one would not be able to keep up and lose data. Having one slow client will reduce the speed of all the other clients. This might not be an issue if you are only deploying clients during night time and out of office hours.
The clients will then use and connect to the fastest possible stream that they can keep up with.
But, using three streams will also cause 3 times as much data in your network.

Another cool thing with Windows Server 2008 R2 multicast is that if one client starts the Multicast stream and has got for example 40% of the data when a second client connects to the stream. The second client will first download 40-100% of the file, and then restart the stream and download 0-40%. So it will not have to wait for the stream to restart before downloading the whole image as in previous versions of Windows Server.

Customers who are not sure that they will be using Multicast or not sure they have configured Multicast correctly in the switches etc may experience very slow deployments with Multicast.
The image transfer may take up to 12 hours.
This is usually caused by Quality of Service in the network equipment. Multicast has not been used that much in the past, and in those cases mostly for Audio and Video services, so some switch/router manufacturers have enabled QoS by default limiting the multicast traffic to ~200kb/sec.
Transferring 7GB of data at 200kb/sec will take a while...

Luckily we have support for both Multicast and Unicast in the same network. At a customer where we experience multicast issues, I'm usually configuring WDS to disconnect a slow client from the multicast stream and let it fallback to unicast. 

From my experience 2048kb/sec (2MB/sec) has been a good average number. The client will always start with a multicast transfer, but if it's too slow it will fall back to unicast. When the customer sorts out any networking problems or disables the Multicast QoS in the switches the client's will automatically use the full power of multicast.
Since a client will start with Multicast and then after a while be disconnected in the above solution it may increase the deployment time slightly. If that is a problem, you can delete the multicast stream and the clients will use unicast directly.
You can later use the PowerShell command Add-SDMulticastStream to recreate the Multicast Stream when it's needed.

You should generally not route multicast traffic over WAN Links. Instead block all Multicast IGMP Traffic over the WAN Link and put a Deployment Server on the other site instead.
And also enable IGMP Snooping on your LAN switches to optimize the bandwidth so the traffic is not broadcased all over your network.
A switch will, by default, flood multicast traffic to all the ports in a broadcast domain (or the VLAN equivalent). Multicast can cause unnecessary load on host devices by requiring them to process packets they have not solicited. When purposefully exploited this is known as one variation of a denial-of-service attack. IGMP snooping is designed to prevent hosts on a local network from receiving traffic for a multicast group they have not explicitly joined. It provides switches with a mechanism to prune multicast traffic from links that do not contain a multicast listener (an IGMP client).
IGMP snooping allows a switch to only forward multicast traffic to the links that have solicited them. Essentially, IGMP snooping is a layer 2 optimization for the layer 3 IGMP. IGMP snooping takes place internally on switches and is not a protocol feature. Snooping is therefore especially useful for bandwidth-intensive IP multicast applications such as IPTV.
Source: http://en.wikipedia.org/wiki/IGMP_snooping

If multiple servers are using multicast functionality on a network (Transport Server, Deployment Server, or another solution), it is important that each server is configured so that the multicast IP addresses do not collide. Otherwise, you may encounter excessive traffic and corrupt/failed deployments when you enable multicasting. Note that each Windows Deployment Services server will have the same default range. To work around this issue, specify static ranges that do not overlap to ensure that each server is using a unique IP address or Multicast Address Dynamic Client Allocation Protocol (MADCAP). Note that you should only use IP addresses inside the Multicast Address range. To specify this option, right-click the server in the MMC snap-in, click Properties, and then click the Network Settings tab.

If you face this problem, you will see Event ID 514 or 515 on your Deployment Servers.

Event Details
Product: Windows Operating System
ID: 514
Source: WDSMC
Version: 6.0
Symbolic Name: EVT_WDSMCS_E_DUPLICATE_MULTICAST_ADDR
Message: The multicast IP address %1 is being used by another Windows Deployment Services server, which has IP %2. Use the Windows Deployment Services management tools to configure your multicast IP address range to avoid this multicast IP address. If you allow this overlap to continue, your network usage will be increased.

Event Details
Product: Windows Operating System
ID: 515 Source: WDSMC
Version: 6.0
Symbolic Name: EVT_WDSMCS_E_NON_WDS_DUPLICATE_MULTICAST_ADDR
Message: The multicast IP address %1 is being used by another multicast server, which has IP %2. Use the Windows Deployment Services management tools to configure your multicast IP address range to avoid this multicast IP address. If you allow this overlap to continue, your network usage will be increased.


Restart the WDS Service to apply your changes.

Friday, February 3, 2012

Recreate the OSDeploy Multicast Stream

If you have deleted your Multicast Stream and would like to use Multicast again for your OS Deployments, this is how to re-create the Stream.

Just start PowerShell on a computer where you have installed Specops Deploy OS Admin Tools 4.5 or later.


Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\Users\Administrator.SPECOPS> Import-Module SpecopsDeploy
PS C:\Users\Administrator.SPECOPS> get-help Add-SDMulticastStream

NAME
    Add-SDMulticastStream

SYNOPSIS
    Creates the Specops Deploy multicast stream on a Specops Deploy Deployment Server

SYNTAX
    Add-SDMulticastStream [-ServerName] <String> [<CommonParameters>]

DESCRIPTION

RELATED LINKS
    http://www.specopssoft.com

REMARKS
    To see the examples, type: "get-help Add-SDMulticastStream -examples".
    For more information, type: "get-help Add-SDMulticastStream -detailed".
    For technical information, type: "get-help Add-SDMulticastStream -full".

PS C:\Users\Administrator.SPECOPS> Add-SDMulticastStream -ServerName PS01
PS C:\Users\Administrator.SPECOPS>

#End of script 

It will re-create the Stream like this;

I had some problems with a Multicast Stream at a customer the other day, it couldn't find the wim-files.
Deleting the Multicast Stream and re-creating it solved the problem in 5 seconds.

Speaking about multicast, don't miss the other posts about multicast.

Thursday, February 2, 2012

No working network card in winpe during deployment.

I ran into a somewhat strange problem at a customer last week.
They were running Windows XP on a virtual machine (VMWare) and we tried to reinstall Windows XP on it with OS Deploy. It couldn't find any network drivers in WindowsPE, so the setup failed.
I change the virtual nic, no difference.
I added all the different virtual nic's thinking that at least one would work.
Still no go. So I imported the drivers from VMTools into OSDeploy and updated (publixhed) the WinPE. But it still didn't work.
We tried another Virtual Machine, with the same virtual nics, and that one worked flawlessly.
Not a driver problem then and it did work in the Windows XP if we booted the machine, it had not been formatted yet since the WinPE couldn't start the scripts. So not a problem with the virtual network cards themselves either. I admit, I were cursing a bit at that time.

I checked the properties of the virtual machine for the 10th time, and suddenly noticed that the Virtual Machine only got 256mb of RAM allocated!
Adjusted that to 1024mb of RAM, booted the Virtual Machine. Wohoo, it worked! The machine suddenly had 3 Virtual network cards, with IP addresses and reinstalled Windows XP with no problem at all.

Yeah, Windows XP was installed manually the first time and it does not need more than 256mb of RAM. But, the WinPE image that we were booting on is a Windows7, which obviously need a bit more RAM to run.

Our developers will laugh and mock me for this.
About a year ago, we had a discussion if we should cover this scenario where a computer does not have enough RAM. Like give a warning or something.
Which, ehum... I said were useless. I didn't think it would be worth spending developer resources to write code for MDT where we could detect if there is not enough RAM in the box and then give a warning. No one is running a machine with just 256mb of RAM these days anyway..... Right ;)

At this point I guess it would have been "a nice to have" feature and could have saved me 15-30 minutes of work and a few gray hairs. But to be fair, I don't think it's a problem anyone will be facing outside a lab environment where you are testing the OS Deployment part and want to keep the RAM to a minimum on your test clients.
And, now when you have read this I'm sure you will remember it and never do the same mistake yourself.

Wednesday, February 1, 2012

Detect OS Architecture with Specops Deploy

Problem: Specops Deploy CSE has problem installing applications on Windows XP 32bit.
But working fine on Windows 7 x86 and x64.

This is logged in Event Log:

   at System.Management.ManagementObjectCollection.get_Count()
   at SpecopsSoft.GroupPolicy.Targets.WqlTargetCriterionItem.IsSatisfied(WindowsIdentity user)
   at SpecopsSoft.GroupPolicy.Targets.TargetCriterionBase.IsSatisfied(WindowsIdentity user)
   at SpecopsSoft.SpecopsDeploy.GpExtension.SpecopsDeployGpExtensionClient.CreateActiveDeploymentList(GpExtensionDataBase[] changedOrNewGpos)
   at SpecopsSoft.SpecopsDeploy.GpExtension.SpecopsDeployGpExtensionClient.ProcessGpos(GroupPolicyObject[] deletedGpos, GpExtensionDataBase[] changedExtensionDatas, WindowsIdentity currentUserIdentity, GpoFlags currentGpoFlags, ManagementScope rsopWmiNamespace)
   at SpecopsSoft.GroupPolicy.GroupPolicyProcessor.ProcessGroupPolicy()




And this information can be found in Specops Debug Logs: 

1/24/2012 4:36:26 PM    1864:1             sogpproc: [EXCEPTION]: An error occurred while processing Group Policy Object, the following is the error message | | | | System.Management.ManagementException: Invalid query |    at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)|    at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()|    at System.Management.ManagementObjectCollection.get_Count()|    at SpecopsSoft.GroupPolicy.Targets.WqlTargetCriterionItem.IsSatisfied(WindowsIdentity user)|    at SpecopsSoft.GroupPolicy.Targets.TargetCriterionBase.IsSatisfied(WindowsIdentity user)|    at SpecopsSoft.SpecopsDeploy.GpExtension.SpecopsDeployGpExtensionClient.CreateActiveDeploymentList(GpExtensionDataBase[] changedOrNewGpos)|    at SpecopsSoft.SpecopsDeploy.GpExtension.SpecopsDeployGpExtensionClient.ProcessGpos(GroupPolicyObject[] deletedGpos, GpExtensionDataBase[] changedExtensionDatas, WindowsIdentity currentUserIdentity, GpoFlags currentGpoFlags, ManagementScope rsopWmiNamespace)|    at SpecopsSoft.GroupPolicy.GroupPolicyProcessor.ProcessGroupPolicy()
1/24/2012 4:36:26 PM    1864:1    sogpproc: Sending _FAILED

Cause: Customer was using a WMI Query that's not supported on Windows XP.
SELECT *
FROM Win32_OperatingSystem
WHERE OSArchitecture = '64-bit'

The OsArchitecture class was not added until Windows Vista according to Microsoft MSDN

Solution: Change the Target so it's using the built-in OS Architecture control to target either x86 or x64 Operating Systems as seen in this picture.