For example, you remove a template from the VM Templates section of the library. This template referenced a VM stored in the VMM Library. Next, you attempt to delete the vhd file itself  from the library, and you receive an error that you cannot delete the file because it has a dependency. When you look at the Dependencies section in the file properties, you see something like this:

If this happens, it should eventually clear up when VMM does some house cleaning. However, you may not be willing to wait for that to happen. In order to delete the template immediately, you can user PowerShell. In this example, I ran the following command to remove the temporary template:

PS C:\Windows\system32> remove-scvmtemplate -vmtemplate "Temporary Template1c2fe 00e-4d16-4975-b85b-8c4fad34fff5"

Once completed, the template (dependency) is removed as seen below:

You will now be able to delete the vhd file.

What’s really cool about dynamic memory is that you can change it while the VM is running. There are limitations, and you can’t change all of the settings, but you can change the minimum and maximum settings, as shown here:

But what if you are running something where you don’t want to use dynamic memory, or where dynamic memory is not recommended? What if you want to set a static amount of memory, but still be able to give it more memory without shutting it down?

Simple. Just set the VM to use dynamic memory, and set the minimum and maximum amounts to the same amount! If you need to increase the memory later, just change the maximum value to the new, higher amount. Note that you won’t be able to increase the minimum amount while it is running, but this will buy you some time until the next shutdown, where you can set the minimum and maximum amounts to the new higher amount.

The steps that follow involve creating a backup of the production group policies and permissions, OU structures, and user accounts. After that backup is created, it is then copied over to the lab environment and imported into the lab Active Directory environment.

These procedures are recommended as a safer alternative to creating a lab using actual system state, P2V, or other backups of production domain controllers. They also are a “cleaner” option, as large environments can contain hundreds of domain controllers, and cleanup operations when using a restore operation in the lab (i.e. metadata cleanup) can be quite extensive. Further, in order to ensure that the lab is properly differentiated from production, the restore method would normally mandate forest/domain renames and compete re-addressing of the IP addressing scheme.

In most cases for lab scenarios, a lab with a similar namespace and imported configurations is more appropriate, and sufficient, as it contains the key AD infrastructure information typically needed for testing.

Detailed Procedures for Creating the Lab AD Environment

Preparations:

1. On a production Windows XP or Windows Server 2003 machine, install the Group Policy Management Console, SP1. This utility can be downloaded here:

https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887

This machine will be used to pull the Active Directory infrastructure information from the production environment. No changes are made to the production environment.

2. Next, also install the GPMC SP1 package on one of the domain controllers in the lab environment.

3. There are two main scripts needed to create the OU and GPO structure in the lab, one for export and the other to import. These scripts are located in the C:\Program Files\GPMC\Scripts directory after installing GPMC.

NOTE: Regarding the steps that follow, GPMC only needs to be installed if you are using Windows 2003 servers. It is available within the OS (Add Features) if you are running 2008 and later. However, the scripts are only included with the version for 2003 as referenced in the link above. If you are using 2008 and later, you’ll need at least one 2003 or XP machine on which to install GPMC. For the source (production), you need to INSTALL the GPMC package - don't just copy the scripts over to an existing machine. Otherwise you will get an "Automation server can't create object" error. For the target (lab), you can just copy the scripts over.

4. Create a folder to accept the files, such as c:\temp\labinfo on the source machine (production side) and also in the lab (target side).

5. From the C:\Program Files\GPMC\Scripts directory on the production side (source), open a command prompt and run the following command which will create an xml and back up all GPO’s:

cscript createxmlfromenvironment.wsf c:\temp\labinfo\production.xml /TemplatePath:C:\temp\labinfo /IncludeAllGroups /IncludeUsers >c:\temp\labinfo\labinfo.log

Note: the above command should be all on one line

(This will store the xml file and the GPO backups in the labinfo folder)

7. Next, copy the contents of the labinfo folder over to the domain controller in the lab (target), in the same location c:\temp\labinfo.

8. From within the labinfo folder on the lab domain controller (target machine), copy all of the gpo backup folders (all of them have GUIDs for names) to the

c:\program files\gpmc\scripts directory on the same lab domain controller:

9. Optional, but highly recommended – take a snapshot of the DC’s in the lab (using Hyper-V) in case something goes wrong, and you want to roll back. Note that you should never use snapshots to backup production DCs that are virtualized, due to risks such as USN rollback. For labs though, it serves as a convenient way to test changes while allowing you to roll back. If you do need to roll back the state of a lab that contains domain controllers, you need to roll the whole lab back to the same point in time. Otherwise, you risk USN rollback, broken secure channels, and other problems. In short, select all the virtual machines, create a snapshot at the same time, and if you need to roll them back, apply the old snapshot to all of them before starting them back up.

10. Open a command prompt and run the following command from within the c:\program files\gpmc\scripts directory on the lab domain controller (target side) to import and create the environment in the lab:

cscript createenvironmentfromxml.wsf /xml:c:\temp\labinfo\production.xml

/CreateUsersEnabled /PasswordForUsers:P@ssw0rd /ImportDefaultGpos

Note: the above command should be all on one line

11. After the script is finished, check the verbose output for errors. Verify that all OU’s, user accounts, group policies and GPO permissions have been imported.

Additional Screen Shots

Production ADUC:

Production GPMC:

Lab ADUC Before Import:

Lab ADUC after Running Script:

Lab GPMC after Running Script:

OU with explicit ACL’s in Production:

OU with Explicit ACL’s in Lab after Running Script:

Limitations

1. Customized ACL’s on OU’s will not import completely due to an API limitation with GPMC. If there are numerous OU’s in the production environment that are using customized permissions, those permissions must be reassigned manually or through the use of additional scripts.

2. User accounts must be located in OU’s on the production side in order to be brought over by the script. The script will not export/import user accounts from the default Users container in the Production environment. If user accounts exist in the default Users container, you may want to move them to an OU before the Export, so that the script will be able to pick them up.

You can try to turn off the Offline Files, delete temporary files, delete offline copies, etc. but sometimes it is easier just to reset the CSC database. If you do this, the result will be as if you had never enabled Offline Files on the client. Then, all you need to do is go back and reselect the folders and files you want to synchronize.

Keep in mind, however, that if you use this command all local copies of the files and folders will be gone (the server side files and folders remain). So, if your latest versions are on the client, you may not want to do this. If, however, you are confident that the server side versions are sufficient, then you can do the following to start fresh with Offline Files on your Windows client.

Run this command from an elevated command prompt:

REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters" /v FormatDatabase /t REG_DWORD /d 1 /f

After running the above command, reboot the client. You can now start fresh with Offline Files on the client machine.

Update: *** WARNING *** These procedures are no longer recommended for any production environment, even temporarily for changing local passwords. At the time of the writing of this article, temporary use of this feature and subsequent deletion of the GPO was a common practice. However, in consideration of heightened security concerns around protecting elevated credentials (even local), this procedure is NOT RECOMMENDED, even temporarily. I left the article in place for historical reference, and I will add some alternative possibilities as another update to this article soon.

With the stricter security requirements that many of my customers have been facing lately, the question about how to change the local administrator password on 10’s, 100’s, or even 1000’s of windows machines has come up several times recently. With the introduction of Group Policy Preferences, this has become a very easy task. Here are some instructions on how to accomplish this with a minimum amount of work on the part of the administrator.

NOTES: These procedures involve making changes to group policies. Thorough testing should always be performed in a lab environment prior to making any changes to group policy in a production environment. Also, GPP’s are not supported in Windows 2000, so these procedures are only useful on XP SP2 and later operating systems.

1. Ensure that the managed clients have the update installed to support group policy preferences. These updates are on Windows Update and can also be found here: https://support.microsoft.com/?kbid=943729

2. On either a Windows Server 2008 server, or on a Vista SP1 client, enable the RSAT (Remote Server Administration) tools. On Vista SP1, they must be installed first, whereas on Server 2008 they only need to be enabled. After installing, enable them by using the Turn On Features option in the Programs and Features applet in the control panel. The RSAT tools can be downloaded here: https://support.microsoft.com/?kbid=941314  Note that just installing the update will not add anything to the Administrative Tools menu. You must also turn the feature on:

Tip: In most open windows in Vista and later operating systems, there is a search box in the upper right hand corner. If you’re not sure how or where to configure a setting, type in a keyword in the search box. In Control Panel, for example, type in something like “screensaver” (without the quotes). You will instantly see relevant settings displayed to help you modify your screensaver. You can save yourself tons of time when looking for features and settings by using this handy search capability.

3. Using the GPMC tool on either Windows Server 2008 or on the Vista SP1 machine with RSAT, note the new Preferences section when editing a group policy:

4. Under Computer Configuration, expand Preferences, Control Panel Settings, and then right-click on Local Users and Groups. Choose New, Local User:

5. Leave the Action drop-down set to Update. From the drop down box for User Name, select Administrator (built-in). Type in a password to reset the password for this account. NOTE: You MUST type in a new password for this step to work. If you do not, the changes will not be made. Optional: UNCHECK the box for Password Never Expires. The end result of these settings will be to have an expiring local password for the built-in admin account, and for the password to be changed to the new value.

You can also use this section to perform other changes, such as renaming the Administrator account or modifying other local accounts.

6. Note the additional settings available via the Common tab:

There is also a good whitepaper on this topic located here. This whitepaper covers GPP’s in more detail, along with their many capabilities.

NOTE: When using Group Policy Preferences, keep in mind that the stored password is obfuscated. From a security standpoint, it would be best to use this procedure to change the password using a separate group policy. Then, once finished, delete the group policy so that the stored password (although obfuscated) is also deleted.