The Deployment Guys

New Command Line Utility to Manage NIC Protocol Bindings

27 Jan 2010 Update - The 32-bit version of this tool is now available as well.

One task which has always been difficult to script on Windows is enabling and disabling protocol bindings for network adapters.  It has now gotten much easier.  Keith Mange from the Hyper-V team has recently released a tool called NVSPBind (Network Virtual Service Provider Bind) for doing just that.

I won’t go into great detail here because John Howard’s blog already has the information you need.  The tool can be downloaded here.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Configuring Regional and Language Settings Online in an MDT Task Sequence

I had a customer who wanted to install the operating system language packs as a dynamic online application installation in the ConfigMgr task sequence based on the region where the client was deployed.  Because of this, they wanted to change the locale settings (UI language, keyboard layout, etc.) dynamically after the language pack was installed.

MDT has the properties UserLocale, SystemLocale (XP/2003), InputLocale (XP/2003), KeyboardLocale (Vista and higher), and UILanguage for configuring locale settings.  (Note that SystemLocale is only a standard property in MDT 2010 and later.  SystemLocale must be added as a custom property for versions of MDT before 2010.)  However, these are only used by MDT to configure these settings in the answer file (Sysprep.inf or Unattend.xml) offline when the operating system image is applied.

To configure these settings online requires using a control panel command with a special answer file that just has locale settings.  These are documented here for Window XP/2003 and Windows Vista and higher:

How to create the regional and language settings for an unattended installation of Windows MultiLanguage Version
http://support.microsoft.com/?id=289125

Windows Vista Command Line Configuration of International Settings
http://msdn.microsoft.com/en-ie/goglobal/bb964650(en-us).aspx

So I created the attached script for Windows XP and Windows Vista to run after the MUI Pack install.  I put this script together right at the end of the engagement (last minute customer request) so it did not get much testing.  I haven’t tried it with Windows 7 but it should work since XML file used should be the same as Windows Vista.  If you encounter problems, please post comments.

This script uses the MDT Properties above and a custom property called GeoID (Vista and higher) to create the appropriate XML or INF settings file (named RegionalOptions.log) and then runs the appropriate command with intl.cpl.  (If SystemLocale is not specified, then the value of UserLocale is used for that.)  You could expand this script to handle other settings using the references links found above.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Added support for 802.1x in Windows PE

Since the dawn of time, Windows PE (WinPE) has not had any support for the 802.1x authentication protocol. This meant that any network deployment of Windows via a network secured with 802.1x was a non-starter, causing headaches for a few on my customers; I actually had one customer that ran new network cables to a majority of the desks in order to be able to deploy Windows XP over the network.

However, thanks in part to a colleague of mine who worked on this, Microsoft has released hotfixes that now add 802.1x support to both WinPE 2.1 and WinPE 3.0. You can get the hotfixes and further information at the below links:

WinPE 2.1: http://support.microsoft.com/kb/975483

WinPE 3.0: http://support.microsoft.com/kb/972831

I wanted to share the links now, but in the near future I will write up a post on how to use these hotfixes in your deployments.

 

This post was contributed by Daniel Oxley a consultant with Microsoft Consulting Services Spain

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

Setting MDT Time Zone Variables from the Source OS Time Zone

System Center Configuration Manager 2007 Operating System Deployment has the ability to migrate the time zone from the source operating system to the destination operating system.  This is done by using the Migrate time zone option in the Capture Windows Settings step of the task sequence.

Unfortunately, MDT Lite Touch Deployment does not offer the same functionality.  So I created a User Exit script (GetCurrentTimeZoneExit.vbs) to query the source OS time zone and set the MDT time zone variable(s).  Using this script with the CustomSettings.ini entries below will always set TimeZoneName and on legacy operating systems (Windows XP/Windows Server 2003 and earlier) it will set TimeZone.  Also, the script can set two custom variables that query WMI for the time zone standard name (TimeZoneStandardName) and the Control Panel description of the time zone (TimeZoneCaption).

Copy GetCurrentTimeZoneExit.vbs to the MDT Scripts folder and add the following entries to CustomSettings.ini:

[Settings]
Priority=TimeZone, TestLegacyOS
Properties=TimeZoneStandardName, TimeZoneCaption, IsLegacyOS

[TimeZone]
UserExit=GetCurrentTimeZoneExit.vbs
TimeZoneStandardName=#GetCurrentTimeZoneWmiProperty("StandardName")#
TimeZoneCaption=#GetCurrentTimeZoneWmiProperty("Caption")#
TimeZoneName=#GetCurrentTimeZoneRegistryKeyName#
IsLegacyOS=#ConvertBooleanToString(%OSCurrentBuild% < 5200)#

[TestLegacyOS]
SubSection=IsLegacyOS-%IsLegacyOS%

[IsLegacyOS-True]
TimeZone=#GetCurrentTimeZoneLegacyIndex#

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Windows 7 GodMode and Other Folder Shortcuts

So you may have seen a couple of blogs about an undocumented feature in Windows 7. This feature allows you to create a folder which then gives access to a large number of shortcuts. The feature has been christened “GodMode” by many bloggers – and I should point out that this is not a name that we use internally at Microsoft. This feature is intended to give developers quick access to areas of the operating system. In case you have missed it – you can create the folder as follows:

1. Create a folder on your desktop

2. Name it DevLinks.{ED7BA470-8E54-465E-825C-99712043E01C}

What ever you put before the period (.) will be the name of the folder created on the desktop (you don’t have to call the folder GodMode)

When you enter the folder you will see a long list of shortcuts to areas within the operating system. It should be pointed out that there are no new tools within this folder – the shortcuts in this folder link to tools, utilities and interfaces that are already available and can be found in Control Panel – it just puts them all into one big list and categorises them.

So if this has wetted your appetite for more shortcut folders, below is a list of additional useful folders that you can create using the same process described above. I have named the folder accordingly to give you a clue as to what each one does:

LOCATION.{00C6D95F-329C-409a-81D7-C46C66EA7F33}
BIOMETRIC.{0142e4d0-fb7a-11dc-ba4a-000ffe7ab428}
POWER.{025A5937-A6BE-4686-A844-36FE4BEC8B6D}
NOTIFICATION.{05d7b0f4-2121-4eff-bf6b-ed3f69b894d9}
CREDENTIALS.{1206F5F1-0569-412C-8FEC-3204630DFB70}
NETWORKAPPS.{15eae92e-f17a-4431-9f28-805e482dafd4}
DEFAULTS.{17cd9488-1228-4b2f-88ce-4298e93e0966}
ASSEMBLIES.{1D2680C9-0E2A-469d-B787-065558BC7D43}
WIRELESS.{1FA9085F-25A2-489B-85D4-86326EEDCD87}
NETWORK.{208D2C60-3AEA-1069-A2D7-08002B30309D}
DRIVES.{20D04FE0-3AEA-1069-A2D8-08002B30309D}
PRINTERS.{2227A280-3AEA-1069-A2DE-08002B30309D}
REMOTE.{241D7C96-F8BF-4F85-B01F-E2B043341A4B}
FIREWALL.{4026492F-2F69-46B8-B9BF-5654FC07E423}
PERFORMANCE.{78F3955E-3B90-4184-BD14-5397C15F1EFC}

Our good friend and ex-deployment guy – Richard Trusson also points out that these are actually Junction Points that link to a name space. For more information take a look at the following link:

http://msdn.microsoft.com/en-us/library/cc144096%28VS.85%29.aspx#virtual

This link has the full list of the GUIDs to create special 'interest' folders:

http://msdn.microsoft.com/en-us/library/ee330741%28VS.85%29.aspx

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Happy Holidays - Windows 7 style

As the final installment in my Windows 7 holiday series, have a look at what is being left for Santa at our house.  These were made from dough from my wife’s batch of Snickerdoodles.  (It’s the final installment because these projects are causing my wife to begin to wonder why she married me.  J )

I know these didn’t turn out as nicely as the pie or the pumpkin.  They looked much better before they went into the oven.  J

 

Happy Holidays from the Deployment Guys.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region.

New Elevation PowerToys Blog

A while back I wrote two articles for TechNet Magazine describing a set of tools to work around a number of shortcomings when trying to elevate some types of tasks in Windows Vista and higher with User Account Control enabled.  I have even written a few posts on this blog that covered them.  You can find these articles here:

Utility Spotlight: Script Elevation PowerToys for Windows Vista
http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx

New Elevation PowerToys for Windows Vista
http://technet.microsoft.com/en-us/magazine/2008.06.elevation.aspx

Since then I have been working on several Elevation PowerToys but have not had the time to sit down and create another large article and tools download.  My experience with blogging here made me realize that the best way to get these new tools to you would be to create a new blog where I could write about and host the new Elevation PowerToys.  It would allow me break up the work by posting about one tool at a time and take feedback on them as well.

So to that end, last month I started the new Elevation PowerToys for Windows blog.  Please drop by and take a look.  I have posted two new Elevation PowerToys there already.  I will also try to place a “heads up” post here whenever I post new tools there.

Thanks to all the other Deployment Guys for being good sports about my posting this here so that our readers could find my new blog.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Where to find DevCon.exe

The DevCon utility acts as a command-line version of Device Manager. Using DevCon, you can enable, disable, restart, update, remove, and query individual devices or groups of devices.  However, because this utility is not part of the operating system many people have had trouble locating the correct version for each OS architecture.

DevCon started life as a sample in the Windows Driver Development Kit.  The first compiled sample for administrator use was provided in Microsoft Knowledge Base article 311272.  However, I recommend that use use the newest versions which are provided in the Windows Server 2003 Service Pack 2 Support Tools.

• The x86 version can be found in the Windows Server 2003 Service Pack 2 32-bit Support Tools: http://www.microsoft.com/downloads/details.aspx?familyid=96A35011-FD83-419D-939B-9A772EA2DF90
• The x64 version can be found in the Support Tools on the Windows Server 2003 Service Pack 2, x64 Editions ISO image file (in the \Support\Tools folder): http://www.microsoft.com/downloads/details.aspx?familyid=8A6EBFB5-833D-44E2-BF92-44648A8BB250
• The Itanium (IA-64) version can be found in the Support Tools on the Windows Server 2003 Service Pack 2 for Itanium-based Systems ISO image file (in the \Support\Tools folder): http://www.microsoft.com/downloads/details.aspx?familyid=803F39EA-50AC-43CA-B564-75C5C080E471

You can extract devcon.exe for each platform from support.cab in each case.

If you need help with using DevCon, here are a few sources of information:

• Devcon Overview
  http://technet.microsoft.com/en-us/library/cc737393(WS.10).aspx
• DEVCON - Command Line Utility Alternative to Device Manager
  http://www.robvanderwoude.com/devcon.php
• The DevCon command-line utility functions as an alternative to Device Manager
  http://support.microsoft.com/?id=311272

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Creating a SID Mapping File with Windows PowerShell

Before I became a “Deployment Guy”, I used to be an “Active Directory Guy” and worked on quite a few Active Directory deployments and migrations.  When users, groups, and computers are migrated to a new domain, the resources (files, shares, user profiles, etc.) need to have the permissions on them changed so that the migrated accounts can access them as before.  If users/groups are migrated before the resources, they can be migrated with SID History (the SID of the old accounts are placed in the sIDHistory attribute of the new account) to allow access to resources before the “security translation” of permissions is completed.

Many domain migration tools like Microsoft’s Active Directory Migration Tool (ADMT) can perform both the object migration and the security translation.  They use their database of migrated objects to do the security translation.  I was brought in on one engagement where a customer had contracted with a vendor to perform their account domain migration with SID History.  However, the resource domains were not migrated at the same time.  They then wanted to collapse their resource domains after the vendor was finished.  Unfortunately, the customer did not own the migration tool that the vendor used and did not have access to the migration database either.

ADMT has the ability to do the security translation using what is called a SID Mapping File.  This is a text file that contain entries that maps the source account to the destination account in either Windows NT account name (domain\name) format or SID format.  The entries look like this:

S-1-5-21-1944836006-1508872116-1651741082-1000,CONTOSO\jsmith

However, this functionality would be of no use without a way of generating the mapping file.  This could be done manually but would be a tremendous task if the account names were changed.  The MCS lead consultant on the project, Alan von Weltin, hit upon the idea of using the SID History information already present in Active Directory to generate the mapping file.  The accounts in AD had the the SIDs of the source accounts in the sIDHistory attribute.  I was asked to write the script that would query for all security principals that had SID History and for each object write a line to the file that mapped each source SID to the Windows NT account name of the new account.

When I first did this, I used VBScript as the scripting language.  Because SIDs in AD are stored as octet strings, converting them to a readable string is not easy in VBScript.  So I used a DLL available in the old ADSI Resource Kit (ADsSecurity.dll) that provided a COM object (ADsSID) for this conversion.  This ADSI Resource Kit has since been discontinued.  Because of this I wanted to create a new version that did not depend on this DLL.

So in my spare time I worked on a version written in Windows PowerShell.  This allows access to the .NET Framework which has classes in the System.DirectoryServices and System.Security namespaces that make searching AD and translating the SIDs to strings relatively easy.  A customer case recently arose where the SID Mapping was needed again.  This inspired me to finally finish this script and publish it here.

Get-SidMappingAD.ps1 will dump a SID mapping from Active Directory.  You must be logged on with an account that has read access to AD.  Use the -help switch for usage.  Note that the mapping from Get-SidMappingAD.ps1 can be generated from objectSid (not useful for  ADMT security translation but useful for documenting source domain SIDs) or sIDHistory.  You have to use the -sidhistory switch to generate the mapping file from sIDHistory.  (You can also dump the “name” field as the object DN.  Not useable by ADMT but useful for documentation.)

I also created a script (Get-SidMappingSAM.ps1) to dump an objectSid,comutername\name mapping file for a local computer SAM database or a Windows NT domain.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region.

A Change in Line-Up

As some of you may have noticed, we have a new Deployment Guy, Samesh Singh.  As you can see from Samesh’s BIO here, he is from Australia and is an expert in deployment technologies.  He has already gotten off to a great start by posting an excellent article about an issue that will likely have tripped a few people up in the past, or if not, you now know how to avoid it!  From the rest of the team, we extend a huge welcome to Samesh; I know he'll be sharing some great posts in the future with everyone.

 

As Samesh joins the team, Richard Trusson leaves.  Richard was one of the founders of this blog and a great colleague and deployment expert, but recently decided to leave Microsoft in order to pursue new ventures.  I am sure (I hope, anyway!) that he has our blog in his RSS feed, so Richard: we wish you all the best for the future!

 

This post was contributed by Daniel Oxley a consultant with Microsoft Consulting Services Spain

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Awesome feature with a catch

Since I’m the newbie in the Deployment Guys, I thought I’d take a step back to Windows Vista to discuss an issue that is not strictly deployment, but affects a deployment, and the steady state of an environment.

I should also add that most of the investigative work was done by one of my clients – I just validated their findings, and we’ve had a successful outcome for them and all of you. So here’s another real example of how we collaborate with our customers to improve everyone’s experience.

Early in the design, the team chose to use driver hosting (see TechNet for how to do this) to provide a central location for devices that were connected by users. This was introduced in Windows Vista, and persists in Windows 7. When a device is plugged in, the system checks the driver hosting path, and enumerates the share to find an appropriate driver without prompting the user for a driver or elevation (unless the driver is not inbox or in the hosting location).

Now consider what happens if you are constantly plugging in a new device? Vista obeys accordingly, and enumerates the location each time. That’s perhaps acceptable if you have only 2 or 3 small drivers, or you have a high speed LAN. But if you are hosting hundreds of megabytes of drivers or traversing a WAN link… you see the problem? The network guys are all over you for messing with their top-talker list!

It turns out that there was a scenario where this occurred for this customer, and can for you as well. A single device was causing this behaviour!

Windows Vista (and later) all have IPv6 enabled by default. However, in Windows Vista/Server 2008 (SP2 or earlier) the IPv6 adapter is reinstalled in some scenarios. Combined with driver hosting, Windows Vista will enumerate the remote driver store each time this occurs. So now you have the network guys complaining that Windows Vista systems are utilising the network excessively.

Depending on when this scenario occurs, the system may:

1. Generate excessive network traffic;

2. Exhibit reduced performance while the device is installed;

3. Have a longer than expected boot or resume time.

So this was recognised, and Microsoft has published a fix that can be found at: http://support.microsoft.com/kb/960670. There is a workaround document in the article as well which is to disable IPv6 adapter if they are not used. But, before you consider disabling IPv6, it is worth reading The Cable Guy’s note.

Happy investigating if it affects your deployment or planned deployment. Network packets never lie – they are just mis-interpreted :)

For those of you deploying Windows 7 or Server 2008 R2 – rest easy! We found this sufficiently early that the fix was integrated into these products prior to RTM.

Samesh.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Samesh Singh a Principal Consultant with Microsoft Services, Australia.

ConfigMgr Admin Console GUID documentor

ConfigMgr allows for great extensibility to perform right click actions. You can find information on this here http://msdn.microsoft.com/en-us/library/cc143056.aspx. Those of you that have done this before know that the first step is digging through the adminconsole.xml file to find the correct GUID in order to add your right click action. Below is a tool that nicely formats the GUIDs for the Root Node, Scope Pane and Results Pane.

In order to use the documentor:

1. Locate your adminconsole.xml file usually located in <ConfigMgr Path>\AdminUI\XMLStorage\Consoleroot\adminconsole.xml and make a copy to adminconsoletemp.xml in a temporary folder. DO NOT EDIT THE ORIGINAL.

2. Copy the attached adminConsoleDocumentor.xsl to the folder with your adminconsoletemp.xml

3. Add the following line to adminconsoletemp.xml after the first line <?xml version="1.0" encoding="utf-8"?>

<?xml-stylesheet type="text/xsl" href="adminConsoleDocumentor.xsl"?>

4. Save the file and load it in Internet Explorer. Your output should look like this:

Share your deployment related right-click actions as comments below!

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Sysprep, Machine SIDs and Other Myths

In a recent blog post, Mark Russinovich wrote about the implications of having duplicate machine Security Identifiers (machine SIDs).  As it turns out, there are likely very few situations where having duplicate machine SIDs causes issues.  Unfortunately, some have gotten the mistaken impression that the discontinuation of NewSID means that nothing needs to be done to prepare an installation of Windows for imaging.  (Mark even specifically states that otherwise.)  Microsoft Knowledge Base article 314828 may also leave this impression since the beginning of the MORE INFORMATION section focuses solely on duplicate SIDs.  (I will be pushing our Support folks to clarify this.)  As I will show, the real “myth” is the idea that changing the SID is the only thing that needs to be done to prepare Windows for cloning.

It is true that one of the reasons we do not support the use of tools other than Sysprep is because these other tools don’t necessarily know about all the places where Windows stashes away references to the machine SID.   However, the main reason is that Sysprep does much more than reset the SID.  Even as far back as Windows NT 4.0, Sysprep has been used to enable a two stage process for deployment.  The first stage was actually running Sysprep.  This would prepare the operating system to be duplicated.  The next stage, Mini-Setup, would run to change the operating system in such a way that it would act as a new, unique installation of Windows.  These stages are now named “generalize” and “specialize” respectively in Windows Vista and higher operating systems.  To simplify things, I will refer to this two stage process as the duplication stages.

The Windows NT 4.0 duplication stages only did a relatively small number of things such as resetting the SID, changing the OEM branding strings, changing the Product ID, and changing the computer names.  However, since Windows 2000 the duplication stages have been tasked with many more items such as disabling/enabling System Restore, removing/regenerating TAPI settings, cleaning the device database/reinitiating full Plug and Play device detection, removing/regenerating network settings, resetting user first run settings and others.  Also, apart from its internal tasks the duplication stages call external “providers” that allow the Windows component developers and third-party application vendors to prepare their components for duplication.  (The Windows 2000/XP version of this process is documented in Microsoft Knowledge Base article 298491.)  Below is the contents of the file that registers the Windows component external providers on Windows 2000/XP, minioc.inf, taken from the Windows 2000 RTM CD:

[Version]
Signature = "$Windows NT$"
DriverVer=11/14/1999,5.00.2183.1

[Components]
NtComponents=ntoc.dll,NtOcSetupProc
Display=desk.cpl,DisplayOcSetupProc

[SysprepInitExecute]
msdtcprx.dll,SysPrepDtcReinstall
catsrvut.dll,SysprepComplus
scecli.dll,SceSysPrep

[SysprepBeforeExecute]
setup\msmqocm.dll,SysprepDeleteQmId

[Global]
WindowTitle=%WINDOW_TITLE%

[Strings]
WINDOW_TITLE      = "Windows 2000 Professional Setup"

As you can see, several external DLLs are called to prepare Windows components for duplication stages.  The number of Windows component providers has only increased with each new version of Windows.  While the Windows Vista and higher Sysprep providers are no longer registered in INF files they still exist (see the Sysprep Provider Developers Guide for details).  There are 26 Windows component providers currently used in Windows 7 during the “generalize” process and 21 used during “specialize” (numbers that could change with any Windows update or service pack).

Because of what I have shown here, I submit that since at least Windows 2000 it was never a best practice to simply run a SID-resetting utility like NewSID to prepare an installation of Windows for duplication.  (It was certainly never a Microsoft recommended best practice.)  These tools simply do not do everything that the Sysprep duplication stages do.  Even if SID regeneration were to be removed from the duplication stages in future versions of Windows, the Microsoft Policy Statement in KB314828 regarding the use of Sysprep is unlikely to change.  With each new version of the operating system the Sysprep duplication stages have become more complex.  Simply removing SID regeneration is unlikely to change this.  Cloning without running Sysprep can affect components such as the Windows Update client when used with Windows Server Update Services, Network Load Balancing , MSDTC, Vista and higher Key Management Server activation, and others.

On the topic of SID duplication itself, I think it would be a mistake to remove SID generation from Sysprep duplication stages. There is at least one case where duplicate SIDs are a problem that Mark discusses where a member server cannot have the same SID as a domain controller.  Therefore, if a server image is used to create the first domain controller for a new domain it cannot but used for any member servers without changing the SID.  Also, having unique local SIDs provides an easy first check as to whether machines were duplicated correctly.  Finally, without a thorough review of the Windows source code and every third party application, I’d say it is premature to say that nothing else depends on unique SIDs.

Although there may be few consequences of SID duplication per se, what the Microsoft development and support teams are really concerned about are installations of Windows that were duplicated without using Sysprep.  Duplicate SIDs are a “symptom” of installations that are improperly duplicated.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region.

Preventing OEM builds from Accidentally Performing Mini-Setup without the Task Sequence

When you pre-load an OEM build on machines, they are usually set-up to perform Mini-setup as soon as they come up. Customers sometimes have difficulties ensuring that these machines boot to WinPE using boot media or PXE rather than simply performing Mini-setup using input from the user. Usually, if this happens, you have to re-sysprep the machine in order to run the task sequence correctly.

This is a little trick you can run at the end of the OEM pre-load task sequence or ask your vendor to perform in order to prevent the machine from accidentally booting to Mini-Setup. Please note, this trick uses the BCD store and thus only works on Windows Vista and Windows 7.

1. Ask your OEM to run the following command at the end of their build process.

bcdedit /set {default} path "This is an OEM Build. Please reboot using your boot media or network connection to continue."

2. Using your deploy task sequence, add the following command line action to your state restore phase.

bcdedit /set {default} path \Windows\System32\winload.exe

If your user accidentally tries to boot the machine, they will get the following message:

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Happy Thanksgiving – Windows 7 Style

Please enjoy this delicious Windows 7 treat baked by my lovely wife.  (Can’t wait to taste it.  J )

 

Happy Thanksgiving from the Deployment Guys.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region.