How to Create a Dell Server Update Utility (SUU) ISO

In this example we are going to walk through the creation of a Dell SUU ISO for 64-bit Windows. The SUU is crucial if you are building out Dell servers as it updates firmware and drivers.

I find the Dell documentation isn’t overly helpful so I’ve put together this quick tutorial on how to create a customized Dell SUU ISO, keep in mind this tutorial creates a Windows based installation ISO.

1. Go and download the latest Dell Repository Manager if you do not have it installed already.

2. Once installed find the icon on your Desktop and launch it.

3. Once launched, you should be prompted to update some plugins, go ahead and do so. If you are prompted to update the Dell Online catalog do so as well.

4. Once the application has loaded, go to the menu bar and select Source > View Dell Online Catalog.

5. If you have not updated the Dell Online Catalog, you should now be prompted to update, click Yes.

6. Under Dup Format check off Windows 64-bit to narrow down the bundles.filter_catalog

7. Check off your System Bundles based on the models you’d like the ISO to support.

8. Once these are all selected click Create Deployment Tools.deployment_tools

9. A wizard will appear, select Create Server Update Utility (SUU) > SUU to ISO. Select Next.

10. Accept the defaults on the Select Plug-ins Select Next. You will be prompted for the SUU export location, select a folder and click OK.

11. On the Summary and Finish page, review the Selected Bundles and confirm that all the appropriate models have been selected for export. Click Finish if everything looks okay. The job will be added to the Jobs Queue where the progress can be seen.

Hyper-V replication in a workgroup or across domains using a self signed certificate.

Why would you want a HyperV server in a workgroup environment?

Well if your Domain Controller is a VM you really don’t want to add the HyperV server to the domain as it will boot before the DC comes up. This type of setup is ripe for domain issues, so we’re left with a server that is only in a workgroup. Also if you are doing cross site replication, you might be replicating from/to different domains, this is where the self signed certificate authentication comes in to play as it is domain agnostic.

Kerberos authentication does not work in this setup, so we need to use a certificate authority as a means of authenticating the two servers with each other. The Primary server is where all the VMs are, and the Replica server is where the VMs will be copied to. HyperV replication is native and built into Server 2012 +, so there are no extra licenses necessary.

What are the steps involved?:

  1. Change the DNS suffix on both Primary and Replica servers.
  2. Reboot both servers.
  3. Create self signed certificates on both servers.
  4. Open the Certificate MMC snap-in on the Primary server and export the certificate to a .pfx file.
  5. Copy the export file and RootCA certificate from the Primary to the Replica server.
  6. Import the Primary RootCA certificate file on the Replica server.
  7. Import the .pfx file on the Replica server.
  8. Copy the RootCA certificate from the Replica to the Primary server and import it.
  9. Disable Certificate Revocation Check on both servers for replication and fail over replication.
  10. Setup the Replica server as a replica in HyperV.
  11. Start replication of a Server on the Primary server.

First we need to change the server names, or rather add a DNS suffix to them. Bring up System Properties in the Control Panel, under the Computer Name tab click change. In the Computer Name/Domain Changes window click More…

In the DNS Suffix and NetBIOS Computer Name add a Primary DNS suffix. Something along the lines of “hypervreplica.local”, it doesn’t matter call it what you will.

Click OK and save all the changes. Note that you will be required to reboot the server in order for changes to take effect. Do this to both the Primary and Replica server.

Primary is the server where your VMs reside, and Replica is where your VMs will be replicated or copied to.

Next we need to create a self signed certificate. For this you will either need Visual Studio or the Windwos SDK(

What we really need out of either of these is the makecert.exe file.

If you have VS installed the makecert.exe file is located under C:\Program Files (x86)\Windows Kits\8.1\bin\x64, or a similar path, the 8.1 will change depending on the version of Visual Studio you have installed.

Copy the makecert.exe file from here to the primary and the replica servers.

On both those servers create an empty directory somewhere, place the makecert file in there. This is also where we will create and store the self signed certificates.

On the Replica server open up an elevated command prompt and navigate to the directory where the “mekecert.exe” file is located and type in the following:

makecert -pe -n “CN=ReplicaRootCA” -ss root -sr LocalMachine -sky signature -r “ReplicaRootCA.cer”

The above command assigns a signature certificate issuer name to the replica server of “ReplicaRootCa”

Followed by:

makecert -pe -n “CN=replicahostname” -ss my -sr LocalMachine -sky exchange -eku, -in “ReplicaRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 ReplicaCert.cer

…where the replicahostname is replaced by the name of the server with the DNS suffix and all. Ex. hostname.domain.local.

Now move over to the Primary server, open up an elevated command prompt and navigate over to the folder where “makecert.exe” is located, and type the following:

makecert -pe -n “CN=PrimaryRootCA” -ss root -sr LocalMachine -sky signature -r “PrimaryRootCA.cer”

Followed by:

makecert -pe -n “CN=primaryhostname” -ss my -sr LocalMachine -sky exchange -eku, -in “PrimaryRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 PrimaryCert.cer

… where the primaryhostname reflects the name of the Primary server with the added DNS suffix. The above 4 commands will create two files on each server.

On the Primary server run > mmc, click File and select Add/Remove Snap-in…

Select the Certificates snap in and click Add>, on the next windows select Computer Account, click Next>, and then select Local computer:. Click Finish.

In the Certificates snap in, expand the Personal store and then click on Certificates.


You should have a certificate here with the Replica serve name and Issued by ReplicaRootCa.

Right click this certificate, select All Tasks and select Export…


This will open the Certificate Export Wizard, when prompted select Yes, export the private key.

Export File Format, use Personal Information Exchange…. (.PFX), Include all certificates and the certification path if possible.

On the Security page check the password box, and input a password you will remember.

Click the Browse button to save the export in a *.pfx file format, give it a file name (PrimaryServer.pfx) and click save.

Double check all your settings on the final page and click Finish.

Copy the PrimaryRootCA.cer file and the PrimaryServer.pfx files to the Replica server. Put it in the folder where you created your Replica Server certificates.

On the Replica server we will now import the cer and pfx files. Open up an elevated command prompt and navigate to the file location. Type in the follwing:

certutil -addstore -f Root “PrimaryRootCA.cer”

The quotes are only necessary if you have spaces or special characters in the file name.

Open up MMC, expand the Personal section, right click on Certificates and select All Tasks > Import.

The Certificate Import Wizard will open up. Click Next. On the File to Import page click Browse…

You might have to change the file type to view the pfx file.

Navigate over to the location of your PrimaryServer.pfx file and select it, click Open. Click Next. On the next screen enter the password for the Private Key. You can mark the key as exportable if you’d like, this means you can export it at a later time if you do not keep a copy of it somewhere. Also check off Include all extended properties. Click Next.

Place the certificate in the Personal certificate store. Click Next. On the final page inspect all the details and make they are correct. Finally click Finish.

*Please be aware that for fail over replication you will more than likely need to export the certificate in the pfx format from both servers and then copy them over and import them on both servers as well. The reason for this is that replication is only one way, where as fail over replication goes both ways. Something to think about.

Now copy the ReplicaRootCA.cer file over to the primary server, place it in the folder with all the other certificate files. In and elevated command prompt add it to the certificate store.

certutil -addstore -f Root “ReplicaRootCA.cer”

Run the following two commands on both servers in an elevated command prompt.

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\FailoverReplication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Note that the only difference between the two registry commands is FailoverReplication and Replication. You shouldn’t need to restart either of the servers after these commands.

Next you need to enable the Replica server as the replica.

On the Replica server open the HyperV manager.

Select HyperV Replication Configuration, in the configuration window check off Enable this computer as a Replica server. Check off Use certificate-based Authentication (HTTPS). It should prompt you to select a certificate, if not click on Select Certificate… you should have the option to select the certificate you created on the Replica server. Select it and click Apply.

*Note, that you will get a prompt about the Windows Firewall, I have mine disabled on all servers so this message never applied to my setup. However if you have your fire wall turned on I would recommend adding a rule to it to allow the traffic on port 443 to pass.

Now the real test, go to your Primary HyperV server and attempt to enable replication. Open up HyperV manager, select a virtual machine, right click it and slect Enable Replication…

You will be presented with a Before You Begin page, click Next >.

On the Specify Replica Server page, type in the FQDN of the replica server, for example, replicahostname.domain.local, or whatever the hostname and dns suffix that you assigned to your replica server is. Click Next >.

On the Specify Connection Parameters, make sure that certificate-based authentication is selected. Kerberos authentication only works on a domain. You may need to select the proper certificate, this will be the Primary server certificate. Also check off Compress the data that is transmitted over the network. If you see a yellow exclamation sign with the text “Could not get configuration details of the specified server.” at the bottom, don’t worry about it, if everything is setup properly it should not impact the replication in any way, shape, or form. Click Next >.

Choose Replication VHDs, here you can pick and choose which storage attached to the server you want to replicate. Select the storage you want and click Next >.

Configure Replication Frequency. The options here are 30 seconds, 5 minutes, or 15 minutes. Depending on how mission critical your data is choose accordingly. Note that replication frequency differs from Server 2012 to Server 2012 R2.

Configure Additional Recovery Points. Depending on how many recovery points you require here is where you set that up. You can setup additional hourly recovery points and even use VSS for snapshots. Hourly recovery points provide granularity, no only can you recover form the last replication point, but with this option enabled you can go back hours. You also have the option of VSS snapshots which, from personal experience, can fail. I don’t have experience with VSS on replication, but VSS on backups and more often than not VSS was always the culprit for failed backups. VSS has a tendency to fail, not ofter but every once in a while. Either way I usually only maintain the latest recovery point. Again the number of recovery points differs from 2012 to 2012 R2, 15 vs 24.

Pick your poison and click Next >.

Choose Initial Replication Method. These options are self explanatory. Chose your replication method and when. I usually just send it over the network, I find that the impact is minimal. You can also start the initial replication at a defined time, perhaps when your system is not as busy at night etc.


*One thing to note about replication and this is important, replication creates an avhdx file. This is a HyperV change file, and during the initial replication this can grow quite large in size. On a normal active system I have observed that this file can grow to 33% size of the original VHDX/VHD file. So be careful and be warned, because if the storage medium runs out of space it will pause the VM.

Click Next >. Confirm your settings and click Finish. Your replication should now begin.

Changing Local Administrator Passwords Remotely

Changing domain and local passwords remotely.

As of May 13 2014 it is no longer possible to create local accounts and assign passwords to them on a domain computer via Group Policy. This was a handy feature when it existed, however Microsoft found that a vulnerability in Group Policy Preferences could allow elevation of privileges.

If you would like further reading on this head over to read about MS14-025.

Here is the KB2962486 article if you would like even more reading on this.

But the basics of it are that Microsoft dropped the ball and the key that was used to encrypt the passwords via Group Policy was published in one of their articles. Total newbs, I hope the incompetent responsible for this got fired for that one.

Either way you can no longer create local accounts on a domain attached computer and set their passwords via group policy. There is a work around but it is no longer fully automated via GPO.

It is a two step process now, and you use the “update” setting instead of “create”  in GPO. You are no longer able to create local account you can however “Update” them. The update feature will create a new account, but it will not set the password. You can use PsTools to set the passwords remotely. Inside the PsTool suite is an executable called PsPasswd.exe that can change local and domian passwords alike.

One thing to note as of this writing is that PsTools, v1.23 of the PsPasswd executable is broken. You will need v1.22 of PsPasswd to accomplish this. It’s not easy to find the v1.22 of the exec but I managed to find a link on the net that works and I’ve shared it via Gdrive.

This works on Windows 7, as for newer versions of Windows I can not comment. I will never move my domain computers to Windows 8+.

Some anti-virus scanners report that one or more of the tools are infected with a “remote admin” virus. None of the PsTools contain viruses, but they have been used by viruses, which is why they can trigger virus notifications. I also assure you I have not altered this zip file in any shape or form, that is beyond me.

PsPasswd usage:

pspasswd [[\\computer[,computer[,..] | @file [-u user [-p psswd]]] Username [NewPassword]

computer Perform the command on the remote computer or computers specified. If you omit the computer name the command runs on the local system, and if you specify a wildcard (\\*), the command runs on all computers in the current domain.

@file Run the command on each computer listed in the text file specified.

-u Specifies optional user name for login to remote computer.

-p Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password.

Username Specifies name of account for password change.

NewPassword New password. If ommitted a NULL password is applied.

For example if you wanted to change a local Admin password on a domain computer named COMPU-DEV1, it would go something like this:

pspasswd \\COMPU-DEV1 -u domain\DomainAdmin -p Password Administrator Password

If you wanted to change the local Admin password on all the computers on the Domain you can execute the following command:

pspasswd \\* -u domain\DomainAdmin -p Password Administrator Password

Alternatively you can do this with a text file. The file needs to contain a single computer name on each line. You can export such file from Active Directory, do this by right clicking the appropriate OU and select Export List… select the Text (Tab Delimited) .txt file format. You’ll have to remove the first line out of the file, and any other columns that aren’t the computer name.

The formatting for PsPasswd with a file is as follows.

pspasswd @c:\locationoffile\computers.txt -u domain\DomainAdmin -p Password Administrator Password

Deploying a WSUS environment with GPO

WSUS or Windows Server Update Services is used on a local network to approve or reject Windows updates and security fixes. The benefits of this system of delivering updates is that it allows you as much or as little control over updates as you want. It’s all about choice. So if you do not want the Windows 10 OS update rolling out to your Windows 7 desktops, you have the ability to prevent that.   

For Server 2012 R2 it’s quite easy to install WSUS. Start up the Server Manager, click Add roles and features, and under Server Roles and Windows Server Update Services select WID Database and WSUS Services. Install the WSUS server role.setup1


Once installed,start up WSUS and you should be greeted by the WSUS Server Configuration Wizard. If that is not the case you can start it manually from the WSUS Options.

There are a few things you should note before you start.setup3

Join the improvement program if you wish. I generally opt out.

Choose the upstream server. If this is your only WSUS server on the network you will synchronize your updates from Microsoft. Otherwise you can opt for another WSUS server on your network.

Set a proxy server if you need to.

Then you will connect to the upstream server by clicking Start Connecting button. This process can take a while and it can actually fail on your first try. Be patient, grab a coffee or something.setup4

Choose the language that you want all your updates in.

Choose which OS or Microsoft Software you want to receive updates for.

Pick which types of updates you want. Generally I pick critical, definition, and security updates.setup7

Configure the Sync Schedule. This sets the time at which WSUS checks for new updates and pulls them down from Microsoft. I generally set this for after business hours.setup8

You can now start the initial sync of Windows Updates for the products you selected, go ahead and grab a long lunch, this can take a while.

Now you can set a couple of other options in the WSUS application. I like to set the Automatic Approvals. This way I’m not approving hundreds of updates every week. I set the Critical and Security updates for WIndows 7 desktops to automatically approve. You can also set it up for a specific group of computers. You can set this group up either manually or via Group Policy. I will cover the group policy method later in the post.setup9

Next go to Computers in WSUS options and select Use Group Policy or registry settings on computers. This option allows you to use group policy to set the computer group membership. This is the preferred method. Close it, the next time the sync runs it should pull all the updates down. Please note that generally during initial setup, when I ran the manual sync it would more often than not fail. I had to wait for WSUS to pull the updates automatically on it’s scheduled evening run.

Now you will have to create two Group Policy Objects. One of the GPOs will be used to set the local update server and other Windows Update options. The other GPO will be used to log users off prior to the updates being applied on the computers. The reason I do this is that the computer will not restart after the updates are pushed if there are any users logged into the computer. The restart is a necessary part of the update.

Here are the things you want to consider when creating these GPOs; when will you be applying these updates, what time of day, which day of the week? These are all questions you should be asking yourself. For instance on my network I schedule my updates for every Wednesday at 10 PM or 22:00. On that same Wednesday evening at 9:30 PM all users are logged off every machine on the network. You don’t want to interfere with your employees but you also don’t want the computer to break from a bad patch or update on a Friday morning. You want to avoid spending the entire Friday and parts of the weekend fixing broken software.

Let’s create the Windows Update policy first:

Open up the Policy Manager either on the server or via Remote Administration Tools.

Create a new policy and name it something like WSUS_Desktops. This will be the desktop update policy and will reside in the OU where all the Network computers are.

Link the new policy to the appropriate OU, it is a good practice to test a policy prior to rolling it out, so maybe first link the GPU to a test OU, or set Item Level Targeting for the time being. This is how I do it on my network.

In the New GPO navigate to Computer Configuration, Policies, Administrative Templates, Windows Components, and Windows Update.GPO1

Open up Windows Update to view the policies in there.GPO2

I only care about 5 of those policies. You can get away with using as few as 2 to push Windows Updates via WSUS using a GPO.

Configure Automatic Updates, this policy setting sets up how the updates are downloaded and how they are scheduled to install. I use option 4 – Auto download and schedule the install. I schedule the install time for every Wednesday at 22:00 or 10pm. Enable it and set the options accordingly for your environment.

Specify intranet Microsoft update service location, this policy setting points the computers to the server where you installed the WSUS application. Please input the http address of the WSUS server and port, for example http://server-name:8530. You don’t need to use a FQDN. If you need to find the port number for your WSUS instance remote into the server where WSUS resides, open IIS Manager, and select Sites, in the right pane you will see all the running websites and which port they are on.GPO3

Enable the policy and input the address in the two fields under the options pane, same address for both the intranet update service and the statistics server.

Automatic Updates detection frequency, this sets the interval at which the desktop computers check back with the WSUS server to see if there are any new windows updates. Default is 22 hours, this setting is optional.

Turn off the upgrade to the latest version of Windows through Windows Update, this will prevent the dreaded Windows 10 update from appearing on your Windows desktop. This is optional but a wise choice if you choose to enable it.

Enable client-side targeting, this policy setting has only one purpose, it is to set the target group in WSUS. Whatever you the group name, this is what the computers that apply this group policy will be sorted under in WSUS. Do not forget to change the Automatic Approvals in WSUS to this group and make sure all the auto approvals are pointing to the right computer group name. The policy will not auto generate the group in WUSUS, you need to manually create it. Once you create it the computers will be auto added to the group.

One thing to consider is that you might want to change the Security Filtering for the GPO. I changed mine to Domain Computers and removed Authenticated Users, since this policy only targets the machines and not the users this made sense. Once the policy is in place for few minutes, you can run the gpupdate command in command line on your test desktop to attempt and update the group policies on said computer.

Then you can check to see which update server the computer is pointing to by running the following command with elevated privileges on the test desktop…

REG QUERY “HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate”

This will show you the WUServer property, which is the Windows Update server address.

If this value or property is not present then then the group policy has not been applied yet, you might need to reboot. Alternatively you can try to manually register the computer with the server using the following command, wuauclt /detectnow.

Once you have that working, now you can create a group policy to log users off before the updates roll out each week. This is necessary as the computers might not reboot if users are still logged on to the desktops during the update process. Users need to log off so that the policy can reboot the PCs and roll out subsequent Windows Updates.

Create a new policy and name it something along the lines of Users Log Off. Link this GPO to the appropriate OU, one where all the network users reside. Again you might want to test the policy first before deploying it to everyone in your Domain. Open the GPO to User Configuration, Preferences, Control Panel Settings, Scheduled Tasks.

Create a new task and call it something along the lines of “Log Off Notify”. This task will notify users 15 minutes prior to logging them off to have them save their work as not to lose it. The task should look similar to the following.

Note the Action for this task is Display a message the message reads “You will be logged off in 15 minutes. Please save and close all your work if you do not wish to lose it.“

In the same Group Policy create another task and call it something along the lines of “Windows Log Off”. This task will log the users off their computers prior to the Windows Updates being applied. It should look like the following.

Note that the Action for this task is Start a program and you are running a force log off command using cmd.exe and switches.

That is it! Run some tests on your test computer to see if the Tasks are being pushed to your workstation. Test the tasks, make sure they work. 

Windows 10 Remote Server Administration Tools finally available.

Despite Windows 10 being more like Windows 8 than Windows 7 and a security nightmare, you might be using it at work and there is also a chance you might want to administer your Active Directory. I prefer this method it is easier to work with than having to RDP to the Domain Controller. Microshaft finally decided to release the RSAT tool kit for Windows 10, and you can grab it here:

Install it on your machine and give it a reboot. Once you reboot your computer head over to Control Panel > Programs and Features > Turn Windows features on or off.

Under Remote Server Administration Tools and Role Administration Tools select the features you might want.adds

Note that the Group Policy Administration Tools feature sits under Remote Server Administration Tools > Feature Administration Tools.GPO

There you go, finally you can manage your domain from the comfort of your desktop. Also to note that these features were all installed by default when I installed Windows 10 RSAT, this might be due to the fact that I upgraded from Windows 7 and it had RSAT installed but when I upgraded Windows 10 did not have an equivalent feature set. I’m thinking there might have been a setting left over from the previous OS version, that’s all. If not be sure to chime in.

All these features can be accessed from the Administrative Tools section in the Control Panel.AdminTools

Noe you have to find a way to enjoy the shitty OS.

AD Security Filtering and Item Level Targeting, apply specific policies to specific resources.

Let’s talk Active Directory again, AD for short. In my opinion is an IT administrators best friend. It has the potential to eliminate the need for log on scripts, it can simplify software deployments to multiple computers, improve security, and eliminate malware. If you’re an IT admin in a small shop or new to the Admin game and haven’t really employed AD on your network beside the default domain policy, I suggest you have a look into it.

What does Security Filtering and Item Level Targeting do exactly? Well they allow you to apply Group Policies to individual users, computers or groups.

FilteringSecurity Filtering is a basic way of filtering out to which group the policy is applied to. For instance, when one creates a new Group Policy Object in Active Directory, by default the GPO applies to Authenticated Users. So any user that logs on to the domain or rather is authenticated by the domain, and exists in the OU where the GPO resides, will have said policy applied when they log in. Now, let’s say you want to limit this to a specific set of users. Perhaps someone in the Accounting department, they might have a specific drive or access to a drive that you want them to have mapped when they log on. This is easy to accomplish with Security Filtering. Please be aware that Security Filtering is not the only way to restrict or grant access to specific network resources, not at all. There are several ways to approach this, some more complicated than others, this is merely just one of those ways.

The benefit of Security Filtering is that you will omit any users, security groups, or computers that are not in this list. It also gives you a somewhat greater control, such as allowing you to set the read write permissions on each group in the policy. Security Filtering is a top level filter, during log on AD will check to see if you are part of said resource and if you are not no further checks will be performed against this policy. The draw back is that no further checks will be performed against this policy, so for for instance if you have a policy that maps various network drives to people in different departments and the drives differ per department you’d have to create new policies for each department. Note: Some people prefer to have separate policies per department, and organize theirs just like this. This method works well for large organizations that need to visually separate policies.

Insert Item level Targeting, it is a nested form of filtering within a specific Active Directory policy. This is where you can have your entire filtering done inside the policy. Perfect for your smaller offices or filtering resources per department. On my network I use Item Level targeting to target specific groups which users are members of to map special drives on their computers. ItemLevel

I don’t have that many users that I support and this is a viable solution to me. For larger scale organizations and to be more transparent with your policies use Security Filtering.

There are many ways to filter groups, users, and computer these are just a couple that are useful.

Side Note: You can also use WMI filters to filter group policies based on specific hardware resources. WMI filters need to be created in the Group Policy Management editor. WMI filters can be created and applied a GPO based on computer attributes, such as the OS, free space, brand, or model. This is perfect if you want to deploy drivers and software to specific machines on your network or range of machines without wanting to add them to a specific group.

Use GPO to set user as a local administrator on a single computer.

This is a revision of a previous post I did. In this version there are fewer steps that need to be performed in the policy. The key here is Item Level targeting, it allows you to apply policies to specific targets in your Active Directory. In this case the target would be a specific computer.

Open up your group policy managment console. Via the run command if you’re on the server, gpmc.msc. I run my policy manager from a Win 7 desktop on the domain, for this you need to install and setup the Remote Server Administration Tools, and run them with Domain Admin credentials. Once you have this open navigate down through your forest and domain to the right organizational unit (ou) where your new admin policy will sit. Generally you want to apply this in the computer OU, as the policy will be affecting desktops on your domain.

Right click on the OU and select “Create a GPO in this domain, and Link it here…“. Give the new Group Policy Object a new name and click OK. Now right click the new GPO and select “Edit…“, this will bring up the GPO editor.


Since this policy applies to a specific computer we will select the Computer Configuration, Preferences, Control Panel Settings, and Local Users and Groups. On the right pane of this option right click and select New, Local Group. In the properties of this for Action: select Update. Group name: will be Administrators (built-in), this is the local Administrators group on all PCs. Rename to: renames the Administrators group on the target PC. Description: is just a description you might want to put in here “Administrators for computer X”. Next click Add under the Members: pane. This will bring up the Local Group Member prompt. In the Name: field type in %DomainName%\userid , where the userid is a specific logon ID and in my case tuser or my domain Test User account. %DomainName% is a variable and in this case it is the domain that the GPO resides in. If you want to see all the available variables hit F3 in the Name: field.

Click OK on the Local Group Member prompt.


Now click the Common tab in the New Local Group Properties window. Here is where we target which computer that this policy will be applied to. On the Common tab check off Item-level targeting and click the Targeting… button.


In the target editor on the top left select New Item and Computer Name. the NetBIOS computer name is should appear. In the pane below click the “” button, here is where you select the computer this policy will apply to. Type in a computer name and click Check Names, it should underline the computer name if found correctly.




Click OK, OK, and OK. Congratulations you have successfully assigned a user to the local administrator group on a single computer on the domain.


You can also rename this to reflect more closely what the Action does. Highlight it and press F2, then rename.



Go ahead, close the Group Policy Management Editor, you’re done.

NOTE: If you want to add a single user on the network as an Administrator on all the network computers your best bet for Item Level targeting is to create a Security Group and make all Domain computers members of this group. One you’ve done that use Item Level targeting and target this said group.