Script to add machines to a WSUS group automatically

#Script to add machines to a WSUS group automatically:
#The script needs Admin credentials and the WSUS Administration Console installed on the machine where it runs
 
#Initialize Variables
 $wsusGroup = [string] "ServerGroupC"
 $wsusParentGroup = [string] "All Computers"
 $date = get-date
 $date = [string] $date.day + $date.month + $date.year + $date.hour + $date.minute
 $succeslog = [string] ".\logs\" + $date + "_success.log"
 $errorlog = [string] ".\logs\" + $date + "_errors.log"
 $WindowsUpdateServer= [string] "winupdate.uvm.edu"
 $useSecureConnection = [bool] $true
 $portNumber = [int] "443"

#Instantiate Objects:
 #Required WSUS Assembly – auto installed with WSUS Administration Tools
 [void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
 if (!$wsus) {
  $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($WindowsUpdateServer,$useSecureConnection,$portNumber)
 }
 $serverList = Get-Content ".\srvlist.txt"
 $updateGroups = $Wsus.GetComputerTargetGroups()
 $updateGroup = $UpdateGroups | Where-Object{$_.Name -eq $wsusgroup} | Where-Object{$_.getparenttargetgroup().name -eq $wsusparentgroup}
 $computerScope = new-object Microsoft.UpdateServices.Administration.ComputerTargetScope
 $computerScope.IncludedInstallationStates = [Microsoft.UpdateServices.Administration.UpdateInstallationStates]::All
 $computers = $wsus.GetComputerTargets($computerScope)
 $wsusServers = @()
 $WsusServersShortNames = @()

#Create arrays:
# $wsusServer = Array of WSUS Computer objects
# $wsusServerShortName = Array strings, with one server RDN per line
Write-Host "Collecting Server List from WSUS…"
$computers | foreach-object {
 $wsusServer = $_.FullDomainName
 #cut off DNS suffix and store shortname
 $wsusServerShortName = $WsusServer.split(‘.’)[0]
 $wsusServers += $WsusServer
 $wsusServersShortNames += $wsusServerShortName
} #End ForEach $computers

#loop to add servers to group
ForEach ($server in $serverList)  {
  #Check if server Netbios name is present in WSUS, if present move to group – if not log an error
  $wsusComputer = $wsusServersShortNames | Where-Object {$_ -eq $server.Trim()} #Checks for a match in WSUS for the current server in the import list.
  If ($wsusComputer) {
   $searchStr = [string] $server.Trim() + "\." #String representing a RegEx match for the relative part of the server FQDN
   $wsusComputer1 = $wsusServers | where-object {$_ -match $searchStr } #Get a WSUS computer object representing the current server in the import list.
   If ($wsusComputer1.getType().Name -match "string") { #Current $wsusComptuer1 must be a [string] object, or next step will fail.
    Write-Host "$wsusComputer1 will be added to $($updateGroup.name) group"
    $computer = $wsus.GetComputerTargetByName($wsusComputer1)
    $updateGroup.AddComputerTarget($computer)
    out-file -append -inputobject "$Server added to $($updategroup.name) group" -filepath $succeslog
   }
   Else {
    #More than one server was matched in WSUS – this will happen if your regEx is not properly formed.
    write-host "count $($wsusComputer1.count)"
    Out-File -append -inputobject "$werver has ambiguous name – check server in WSUS and add to group manually" -filepath $errorlog
   } 
  } #End If $wsusComputer
 Else {
  Write-Host "$Server not found in WSUS"
  out-file -append -inputobject "$Server not found in WSUS" -filepath $errorlog
 } 
} 

#End ForEach $server

Steps to move a DHCP database from a Windows Server 2003 or 2008 to another Windows Server 2008 machine

The DHCP database can be moved or migrated from a Windows Server 2003 server to a Windows Server 2008 server, or from one Windows Server 2008 server to another.  The information below details the necessary steps.

Export the DHCP database from a server that is running Microsoft Windows Server 2003 or Windows Server 2008

To move a DHCP database and configuration from a server that is running Windows Server 2003 or Windows Server 2008 to another server that is running Windows Server 2008:

1.   Log on to the source DHCP server by using an account that is a member of the local Administrators group.

2.   Click Start, click Run, type cmd in the Open box, and then click OK.

3.   Type netsh dhcp server export C:\dhcp.txt all , and then press ENTER.

Note: You must have local administrator permissions to export the data.

Configure the DHCP server service on the server that is running Windows Server 2008

1.   Click Start, click Administrative Tools, click Server Manager. If needed acknowledge User Account Control.

2.   In Roles Summary click Add Roles, click Next, check DHCP server, and then click Next.

Import the DHCP database

1.   Log on as a user who is an explicit member of the local Administrators group. A user account in a group that is a member of the local Administrators group will not work. If a local Administrators account does not exist for the domain controller, restart the computer in Directory Services Restore Mode, and use the administrator account to import the database as described later in this section.

2.   Copy the exported DHCP database file to the local hard disk of the Windows Server 2008-based computer.

3.   Verify that the DHCP service is started on the Windows Server 2008-based computer.

4.   Click Start, click Run, type cmd in the Open box, and then click OK.

5.   At the command prompt, type netsh dhcp server import c:\dhcpdatabase.txt all , and then press ENTER, wherec:\dhcpdatabase.txt is the full path and file name of the database file that you copied to the server.

Note When you try to export a DHCP database from a Windows 2000/2003 domain controller to a Windows Server 2008member server of the domain, you may receive the following error message:

         Error initializing and reading the service configuration - Access Denied

Note You must have local administrator permissions to import the data.

6.   To resolve this issue, add the Windows Server 2008 DHCP server computer to the DHCP Admins group at the Enterprise level and redo steps 4 & 5.

7.   If the "access is denied" error message occurs after you add the Windows Server 2008 DCHP server computer to the DHCP Admins group at the Enterprise level that is mentioned in step 6, verify that the user account that is currently used to import belongs to the local Administrators group. If the account does not belong to this group, add the account to that group, or log on as a local administrator to complete the import and redo steps 4 & 5.

Authorize the DHCP server

1.   Click Start, point to All Programs, point to Administrative Tools, and then click DHCP.

Note You must be logged on to the server by using an account that is a member of the Administrators group. In an Active Directory domain, you must be logged on to the server by using an account that is a member of the Enterprise Administrators group.

2.   In the console tree of the DHCP snap-in, expand the new DHCP server. If there is a red arrow in the lower-right corner of the server object, the server has not yet been authorized.

3.   Right-click the server object, and then click Authorize.

4.   After several moments, right-click the server again, and then click Refresh. A green arrow indicates that the DHCP server is authorized.

Windows 2003 Server Hang Issue

Action plan 1 - procedure to generate the MPS reports:

*can be generated at any point of time.

Please download and run the MPS reports downloaded from the link

http://download.microsoft.com/download/b/b/1/bb139fcb-4aac-4fe5-a579-30b0bd915706/MPSRPT_SETUPPerf.EXE

On your system a CAB file will be generated for your convenience in the %systemroot%\MPSReports\Setup\<Report Type>\Cab directory called:

%COMPUTERNAME%_MPSReports.CAB. 

Action plan 2 - to collect Poolmon logs:

*need to run till the issue occurs.

Poolmon: Download the Poolmon3vbs.zip tool online and run the batch file _logpoolmon-as-a-service.cmd in the poolmon folder,

a.     The logs will be generated in the same folder where the poolmon is downloaded to. (Eg. Desktop or C drive)

b.      The complete log folder (Poolmon output) can be used for the analysis

Action plan 3 - System monitor (Performance Monitor):

*need to run till the issue occurs.

We can monitor the performance on the server where you are facing the problem. Please follow the below mentioned commands to setup a remote performance monitoring to this server.

          - Permanently disable all screen savers on the server.

         - As the server hangs so we would have to remotely monitor the server (with the issue) from another Windows 2003 server which does not have any issues and enough drive space.. 

         - Go to the PC (without any issues). Start, Run and type "Perfmon" (without quotation marks) and press OK. 

         - Expand Performance Logs and Alerts. Highlight Counter Logs and right click in the right pane to bring up a menu. From this menu, select "New Log Settings". Give this log a name.

         - Press Add counters. Type in the server name that we want to monitor (Example: in the format: \\Servername) in the "Select counters from computer:" drop-down. 

         - Add "All counters" and "All instances" each of the following objects: 

             Memory 

             Network Interface 

             Objects 

             Paging File 

             Physical Disk 

             Process 

             Processor 

             Redirector 

             Server 

             Server Work Queues 

             System 

         - Set the Interval for every 15 Seconds. 

         - Click on the Log Files tab and set Log file type to Binary Circular File and a Limit of 800,000 KB. Please make sure where the Log is currently save have enough disk space to accommodate.

         - Go to the schedule tab, set the schedule for "Stop Log- Manually" and "Start Log- Manually. 

           

Here is an article for reference: 248345 How to Create a Log Using System Monitor in Windows 2000 http://support.microsoft.com/?id=248345

Action plan 4 - procedure to generate a complete memory dump when the server hangs:

We can configure the machine for a complete memory dump with a registry setting.

Here are the instructions for configuring the machine so that we can create a complete memory dump

First make sure that the machine is setup to get a complete memory dump: 

        1)   In Control Panel, Select the System Applet 

        2)   Select the Advanced tab 

        3)   Click the "Startup and Recovery" button 

        4)   Under the "Write Debugging Information" section select: 

              "Complete Memory Dump" from the drop down menu 

        5)   Make sure the check mark is placed on: 

              "Overwrite any existing file" 

        6)   Make sure that there is a paging file (pagefile.sys) on the System Drive and that it is at least RAM + (.5 x RAM). 

        7)   Also make sure there is more space on the hard drive than there is physical RAM 

Second, configure the system for a dump memory: 

        8)   Start Registry Editor (Regedt32.exe).  

        9)   Locate the following key in the registry:   

              HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters  

        10) On the Edit menu, click Add Value, and then add the following registry value: 

              Value Name: CrashOnCtrlScroll   

              Data Type: REG_DWORD   

              Value: 1  

        11) Quit Registry Editor.

        12) Then reboot the machine.  

Now, hold down the RIGHT CTRL key, and press the RIGHT SCROLL LOCK key twice.  

You can use for all the action plan to fix the server hang issues.

Blue Screen View - BSOD utility

A great utility I have come across lets you find answers for the weird Blue Screen of Death errors - (BSOD)

I have been able to fix many issues using this small piece of software.

Available for download to you all enjoy :)

http://dl.dropbox.com/u/92862901/BlueScreenView.zip

Description
===========

BlueScreenView scans all your minidump files created during 'blue screen
of death' crashes, and displays the information about all crashes in one
table. For each crash, BlueScreenView displays the minidump filename, the
date/time of the crash, the basic crash information displayed in the blue
screen (Bug Check Code and 4 parameters), and the details of the driver
or module that possibly caused the crash (filename, product name, file
description, and file version).
For each crash displayed in the upper pane, you can view the details of
the device drivers loaded during the crash in the lower pane.
BlueScreenView also mark the drivers that their addresses found in the
crash stack, so you can easily locate the suspected drivers that possibly
caused the crash.

BlueScreenView Features

=======================

* Automatically scans your current minidump folder and displays the

  list of all crash dumps, including crash dump date/time and crash

  details.

* Allows you to view a blue screen which is very similar to the one

  that Windows displayed during the crash.

* BlueScreenView enumerates the memory addresses inside the stack of

  the crash, and find all drivers/modules that might be involved in the

  crash.

* BlueScreenView also allows you to work with another instance of

  Windows, simply by choosing the right minidump folder (In Advanced

  Options).

* BlueScreenView automatically locate the drivers appeared in the crash

  dump, and extract their version resource information, including product

  name, file version, company, and file description.

Windows 7 x64 and printers hosted on Windows server 2003

The first obstacle which I've had to overcome that was worthy of a post is regarding network printer installations on a Windows 7 64 bit client. Nice and easy you say, however our printer servers are running Windows server 2003 32bit and when I try to connect to them from a Win7 client, it tells me no drivers are available and that's that.

Well I found an easy solution to allow Win7 clients to install these printers ok and avoid having users go and browse for drivers etc. Users are stupid and if you give them a choice, they will pick the wrong one.

Here's what I did

Jump onto your Windows server 2003 box and open printers and faxes
Right-Click on one of your network printers and properties
Click on the Sharing tab
Click on the Additional Drivers button
Tick the box for x64 (see below)
Now browse for your Windows Server 2003 x64 drivers (which you downloaded in advance!) and let the server install them.

Despite those being drivers for Windows Server 2003 x64, my Windows 7 x64 clients happily installed the printer and are able to print just fine.  We use leased Toshiba e-Studio multi function printers which are a great idea for cost effective communal office printing rather than operating expensive individual laser-jet printers but this is a blog topic for another day.

Do You Have Users Hiding in Your Enterprise Servers?

Are you in control of the user accounts across your enterprise systems? Defunct user accounts, duplicate IDs, excessive rights – do these plague your current accounts database? More importantly - how many account databases are you maintaining…or failing to maintain?

Identity services like authentication and single sign-on are critical in today’s business environments.  Managing these services is often a manual process, complicated by redundancy and integration between systems.  Employees may have network credentials sprawled across multiple directory services or local accounts.  The proliferation of virtual machines and self-service deployment can make resource control even more challenging.  (link to previous blog on virtual server sprawl). When a person changes roles or leaves the company how do you know that all their credentials have been remove? Do you have users lurking in a local UNIX or Linux /etc/passwd file? Do you have the necessary tools to ensure that user account authorization is synchronized and up-to-date throughout your organization?

You need an integrated solution to manage and authenticate users in the same way across all platforms.  A solution that will granularly control access to sensitive resources, apply uniform policies, and provide detailed auditing and reporting on the state of your network security.  By leveraging your existing Active Directory infrastructure you can integrate your UNIX, Linux, and Max OS clients and servers and consolidate to a single directly service – and a single point of management - for account control and authorization. 

Power Broker Identity Services is a comprehensive Active Directory bridge solution delivering consolidated management, control and out-of-box compliance reporting.   With PowerBroker Identity Services you can eliminate security and compliance concerns. You can reduce the management overhead -- and overload -- of maintaining obsolete account services, such as NIS, or ad hoc directory services, such as custom LDAP implementations.  You can also, improve security with enhanced account control, Kerberos authentication, and integrated cross-platform group policy support and with single sign-On (SSO) for your Linux, UNIX and Mac OS X systems you can streamline the user experience and further enhance security.  Plus, with out-of-box compliance reports you can complete audits quickly and successfully.

PowerBroker Identity Services coupled with Active Directory provide a proven Identity Management System to deliver integrated authentication, secure authorization, consolidated management, and one-click reporting to help you meet compliance requirements.

Exchange 2003 Alias not working

I renamed an account in ADUC and I changed  the username, the account

details (name, address, phone #, etc) as well as the "Alias" field on

the Exchange General tab. (The email address was staying the same.) I

made sure the GAL was correct and then updated the Offline Address

Book. In Outlook, I went to "Send/Receive" and "Download Address Book".

However, when I begin typing in the the new user's name, it is the

*old* user whose alias displays next to the new user's name

Check if  recipient update service set to always run?

You can manually run the Recipient Update Service to update the user

information in the Global Address List. To do this, follow these steps:

1. Open Exchange System Manager.

2. Expand Recipients, and then click Recipient Update Service.

3. In the right pane, right-click Recipient Update Service (yourdomain.com)

and then click Update Now

& It worked :)

The Machine SID Duplication Myth (and Why Sysprep Matters)

On November 3 2009, Sysinternals retired NewSID, a utility that changes a computers machine Security Identifier (machine SID). I wrote NewSID in 1997 (its original name was NTSID) because the only tool available at the time for changing machine SIDs was the Microsoft Sysprep tool, and Sysprep doesn’t support changing the SIDs of computers that have applications installed. A machine SID is a unique identifier generated by Windows Setup that Windows uses as the basis for the SIDs for administrator-defined local accounts and groups. After a user logs on to a system, they are represented by their account and group SIDs with respect to object authorization (permissions checks). If two machines have the same machine SID, then accounts or groups on those systems might have the same SID. It’s therefore obvious that having multiple computers with the same machine SID on a network poses a security risk, right? At least that’s been the conventional wisdom.

The reason that I began considering NewSID for retirement is that, although people generally reported success with it on Windows Vista, I hadn’t fully tested it myself and I got occasional reports that some Windows component would fail after NewSID was used. When I set out to look into the reports I took a step back to understand how duplicate SIDs could cause problems, a belief that I had taken on faith like everyone else. The more I thought about it, the more I became convinced that machine SID duplication – having multiple computers with the same machine SID – doesn’t pose any problem, security or otherwise. I took my conclusion to the Windows security and deployment teams and no one could come up with a scenario where two systems with the same machine SID, whether in a Workgroup or a Domain, would cause an issue. At that point the decision to retire NewSID became obvious.

I realize that the news that it’s okay to have duplicate machine SIDs comes as a surprise to many, especially since changing SIDs on imaged systems has been a fundamental principle of image deployment since Windows NT’s inception. This blog post debunks the myth with facts by first describing the machine SID, explaining how Windows uses SIDs, and then showing that - with one exception - Windows never exposes a machine SID outside its computer, proving that it’s okay to have systems with the same machine SID. Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so MIcrosoft's support policy will still require cloned systems to be made unique with Sysprep.

SIDs

Windows uses SIDs to represent not just machines, but all security principals. Security principals include machines, domain computer accounts, users and security groups. Names are simply user-friendly representations for SIDs, allowing you to rename an account and not have to update access control lists (ACLs) that reference the account to reflect the change. A SID is a variable-length numeric value that consists of a structure revision number, a 48-bit identifier authority value, and a variable number of 32-bit subauthority or relative identifier (RID) values. The authority value identifies the agent that issued the SID, and this agent is typically a Windows local system or a domain. Subauthority values identify trustees relative to the issuing authority, and RIDs are simply a way for Windows to create unique SIDs based on a common base SID.

You can use the Sysinternals PsGetSid tool to view a machine’s SID by running it with no command-line arguments:

Here, the revision number is 1, the authority is 5, and there are four subauthority values. At one point during the design of Windows NT, the machine SID might have been used for network identification, so in order to assure uniqueness, the SID that Setup generates has one fixed subauthority value (21) and three randomly-generated subauthority values (the numbers following “S-1-5-21” in the output). 

Even before you create the first user account on a system, Windows defines several built-in users and groups, including the Administrator and Guest accounts. Instead of generating new random SIDs for these accounts, Windows ensures their uniqueness by simply appending a per-account unique number, called a Relative Identifier (RID), to the machine SID. The RIDs for these initial accounts are predefined, so the Administrator user always has a RID of 500:

After installation, Windows assigns new local user and group accounts with RIDs starting at 1000. You can use PsGetSid to view the name of the account for a specified SID, and here you can see that the local SID that has a RID of 1000 is for the Abby account, the name of the administrator account Windows prompted me to name during setup:

In addition to these dynamically created SIDs, Windows defines a number of accounts that always have predefined SIDs, not just RIDs. One example is the Everyone group, which has the SID S-1-1-0 on every Windows system:

Another example, is the Local System account (System), which is the account in which several system processes like Session Manager (Smss.exe), the Service Control Manager (Services.exe) and Winlogon (Winlogon.exe) run:

SIDs and Access Control Lists

When an account logs on to a Windows system, the Local Security Authority Subsystem (LSASS -Lsass.exe) creates a logon session and a token for the session. A token is a data structure the Windows kernel defines to represent the account and it contains the account’s SID, the SIDs of the groups that the account belongs to at the time it authenticated, and the security privileges assigned to the account and the groups. When the last token that references a logon session is deleted, LSASS deletes the logon session and the user is considered logged off. Here you can see my interactive logon session, displayed with the Sysinternals LogonSessions utility:

And here you can see a token Lsass has created for the session in Process Explorer’s handle view. Note that number following the account name, 7fdee, matches the logon session ID shown by LogonSessions:

By default, processes inherit a copy of their parent process’s token. Every process running in my interactive session, for example, has a copy of the token that they inherited originally from the Userinit.exe process, the process Winlogon creates as the first of any interactive logon. You can view the contents of a process’s token by double-clicking on the process inProcess Explorer and switching to the Security page of the process properties dialog:

When one of my processes opens an operating system object, like a file or registry key, the security subsystem executes a permission check that evaluates entries in the object’s access control list (ACL) that reference a SID included in the process’s token.

A similar check happens for remote logon sessions, which are the kind created by a “net use” of a remote computer’s share. To successfully connect to a share you must authenticate to the remote system with an account known to that system. If the computer is part of a Workgroup, then the credentials you specify must be for a local account on the remote system; for a Domain-joined system, the credentials can be for a remote system’s local account or a Domain account. When you access a file on the share, the file server driver on that system uses the token from the logon session for the permission check, leveraging a mechanism called impersonation.

SID Duplication

The Microsoft-supported way to create a Windows installation that’s ready for deployment to a group of computers is to install Windows on a reference computer and prepare the system for cloning by running the Sysprep tool. This is calledgeneralizing the image, because when you boot an image created using this process, Sysprep specializes the installation by generating a new machine SID, triggering plug-and-play hardware detection, resetting the product activation clock, and setting other configuration data like the new computer name.

However, some IT administrators install Windows on one of their systems, install and configure applications, then use deployment tools that don’t reset the SIDs of the copies of the Windows installations. The best practice up to now has been to run a SID-resetting utility like NewSID to change SIDs. These utilities generate a new machine SID, try to find all the locations on a system, including all the file system and registry ACLs, that contain copies of the machine SID, and update them to the new SID. The reason that Microsoft doesn’t support systems modified in this way is that, unlike Sysprep, these tools don’t necessarily know about all the places where Windows stashes away references to the machine SID. The reliability and security of a system that has a mix of the old and new machine SID can’t be guaranteed.

So is having multiple computers with the same machine SID a problem? The only way it would be is if Windows ever references the machine SIDs of other computers. For example, if when you connected to a remote system, the local machine SID was transmitted to the remote one and used in permissions checks, duplicate SIDs would pose a security problem because the remote system wouldn’t be able to distinguish the SID of the inbound remote account from a local account with the same SID (where the SIDs of both accounts have the same machine SID as their base and the same RID). However as we reviewed, Windows doesn’t allow you to authenticate to another computer using an account known only to the local computer. Instead, you have to specify credentials for either an account local to the remote system or to a Domain account for a Domain the remote computer trusts. The remote computer retrieves the SIDs for a local account from its own Security Accounts Database (SAM) and for a Domain account from the Active Directory database on a Domain Controller (DC). The remote computer never references the machine SID of the connecting computer.

In other words, it’s not the SID that ultimately gates access to a computer, but an account’s user name and password: simply knowing the SID of an account on a remote system doesn’t allow you access to the computer or any resources on it.  As further evidence that a SID isn’t sufficient, remember that built-in accounts like the Local System account have the same SID on every computer, something that would be a major security hole if it was.

As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s the machine SID of the system that became the Domain’s first DC, and all machine SIDs for the Domain’s DCs match the Domain SID. So in some sense, that’s a case where machine SIDs do get referenced by other computers. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems.

Some articles on SID duplication, including this KB article, warn that if multiple computers have the same SID, that resources on removable media like an NTFS-formatted firewire disk can’t be secured to a local account. What they fail to mention is that permissions on removable media provide no security regardless, because a user can connect them to computers running operating systems that don’t honor NTFS permissions. Moreover, removable media tend to have default permissions that grant access to well-known SIDs, such as to the Administrators group, which are the same on all systems. That’s the fundamental rule of physical security and why Windows 7 introduced Bitlocker-to-Go, which enables you to encrypt removable storage.

The final case where SID duplication would be an issue is if a distributed application used machine SIDs to uniquely identify computers. No Microsoft software does so and using the machine SID in that way doesn’t work just for the fact that all DC’s have the same machine SID. Software that relies on unique computer identities either uses computer names or computer Domain SIDs (the SID of the computer accounts in the Domain).

The New Best Practice

It’s a little surprising that the SID duplication issue has gone unquestioned for so long, but everyone has assumed that someone else knew exactly why it was a problem. To my chagrin, NewSID has never really done anything useful and there’s no reason to miss it now that it’s retired. Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft’s support policy will still require cloned systems to be made unique with Sysprep