Change Windows Server 2012 Product Key

 Windows did not allow me to change the key from any of the GUI's

Use the PowerShell....

1.	Clear The Current Key Open Powershell with admin rights then enter: slmgr -upk (this removes the current Product Key)
2.	Add The New (or Correct Key) Now that the key is cleared you can either stay in Powershell and enter the new key with the following: slmgr -ipk XXXX-XXXX-XXXX-XXXX (with the X's of course being the Key ) or Go the the activation GUI and you will now be able to enter a Key

Error 0x8007232b or 0x8007007B occurs when you try to activate Windows

Change the product key to an MAK. To do this, follow these steps:

1. Click Start
   
   , click All Programs, click Accessories, and then right-click Command Prompt.
2. Click Run as administrator.
   
   
   
   If you are prompted for an administrator password or for confirmation, type the password or provide confirmation.
3. At the command prompt, type the following command, and then press Enter:
   slmgr -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
   
   Note In this command, the placeholder xxxxx-xxxxx-xxxxx-xxxxx-xxxxx represents your MAK product key.

DFS Namespaces and DFS Replication Overview

Applies To: Windows Server 2012, Windows Server 2012 R2

This topic discusses the DFS Namespaces (DFSN or DFS-N) and DFS Replication (DFSR or DFS-R) role services, which together comprise Distributed File System (DFS) in Windows Server 2012 R2 and Windows Server 2012. This topic discusses how to install DFS, what’s new, and where to find evaluation and deployment information.
Did you mean…

• What's New in DFS Replication in Windows Server 2012 R2
  
  
• DFS Management (online Help)
  
• DFS Step-by-Step Guide for Windows Server 2008
  
  
• DFS Replication: Frequently Asked Questions
  
  
• DFS Namespaces: Frequently Asked Questions
  
  

Role service descriptions

DFS Namespaces and DFS Replication are role services in the File and Storage Services role.

• DFS Namespaces   Enables you to group shared folders that are located on different servers into one or more logically structured namespaces. Each namespace appears to users as a single shared folder with a series of subfolders. However, the underlying structure of the namespace can consist of numerous file shares that are located on different servers and in multiple sites.
  
• DFS Replication   Enables you to efficiently replicate folders (including those referred to by a DFS namespace path) across multiple servers and sites. DFS Replication uses a compression algorithm known as remote differential compression (RDC). RDC detects changes to the data in a file, and it enables DFS Replication to replicate only the changed file blocks instead of the entire file.
  

Practical applications

New and changed functionality

Removed or deprecated functionality

Requirements for running DFS

Server Manager information

Interoperability with Azure virtual machines

See also

Installing AD DS from Media

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

You can use the Ntdsutil.exe tool to create installation media for additional domain controllers that you are creating in a domain. By using the Install from Media (IFM) option, you can minimize the replication of directory data over the network. This helps you install additional domain controllers in remote sites more efficiently.
Ntdsutil.exe can create four types of installation media, as described in the following table.
You must use read-only domain controller (RODC) installation media to install an RODC. For RODC installation media, the ntdsutil command removes any cached secrets, such as passwords. You can create RODC installation media either on an RODC or on a writeable domain controller. You must use writeable domain controller installation media to install a writeable domain controller. You can create writeable domain controller installation media only on a writeable domain controller.
If the source domain controller where you create the installation media and the destination server where you plan to install Active Directory Domain Services (AD DS) both run Windows Server 2008 with Service Pack 2 or later or Windows Server 2008 R2, and if you are using Distributed File System (DFS) Replication for SYSVOL, you can run the ntdsutil ifm command with an option to include the SYSVOL shared folder in the installation media. If the installation media includes SYSVOL, you must use Robocopy.exe to copy the installation media from the source domain controller to the destination server. For more information, see Installing an Additional Domain Controller by Using IFM.

 

Type of installation media	Parameter	Description
Full (or writable) domain controller	Create Full PathToMediaFolder	Creates installation media for a writable domain controller or an Active Directory Lightweight Directory Services (AD LDS) instance in the folder that is identified in the path.
RODC	Create RODC PathToMediaFolder	Creates installation media for an RODC in the folder that is identified in the path.
Full (or writable) domain controller with SYSVOL Important This option works only for domain controllers that run Windows Server 2008 R2	Create Sysvol Full PathToMediaFolder	Creates installation media for a writable domain controller with SYSVOL in the folder that is identified in the path.
RODC with SYSVOL Important This option works only for domain controllers that run Windows Server 2008 R2	Create Sysvol RODC PathToMediaFolder	Creates installation media for an RODC with SYSVOL in the folder that is identified in the path.

You cannot run the ifm command on a domain controller that runs Windows Server 2003. However, you can create a backup of a Windows Server 2003 domain controller and then use the dcpromo /adv command to create a Windows Server 2003 domain controller.
Installation from media does not work across different operating system versions. In other words, you must use a Windows Server 2008 domain controller to generate installation media to use for another Windows Server 2008 domain controller installation.
When the Active Directory Recycle Bin is enabled, any installation media that was created before the Active Directory Recycle Bin was enabled is no longer valid. Create new installation media while Active Directory Recycle Bin is enabled.
You can use a 32-bit domain controller to generate installation media for a 64-bit domain controller, the reverse is also true.
You can use the following procedure to create installation media for AD DS.
Administrative Credentials
To create installation media for AD DS, you must be able to log on to a domain controller interactively and be able to make a backup. On a writable domain controller, this means that you must be a member of the Builtin Administrators, Server Operators, Domain Admins, or the Enterprise Admins groups to perform the following procedure.
On an RODC, a user that you delegate can create the installation media, but you can only create RODC installation media (not installation media for a writable domain controller) on an RODC.

To create installation media

---

1. Click Start, right-click Command Prompt, and then click Run as administrator to open an elevated command prompt.
2. At the command prompt, type the following command, and then press ENTER:
   
   Copy

   ntdsutil
   

3. At the ntdsutil prompt, type the following command, and then press ENTER:
   
   Copy

   activate instance ntds
   

4. At the ntdsutil prompt, type the following command, and then press ENTER:
   
   Copy

   ifm
   

5. At the ifm: prompt, type the command for the type of installation media that you want to create (as listed in the table earlier in this topic), and then press ENTER.
   For example, to create RODC installation media, type the following command, and then press ENTER:
   
   Copy

   create rodc C:\InstallationMedia
   

   Where C:\InstallationMedia is the path to the folder where you want the installation media to be created.
   You can save the installation media to a network shared folder or to any other type of removable media.
   

   Note
   The IFM process creates a temp database in the %TMP% folder. You need at least 110% of the size of the AD DS or AD LDS database free on the drive where the %TMP% folder is in order for the operation to succeed. You can redirect the %TMP% folder to another disk on the server in order to use more space.

When you create additional domain controllers in the domain, you can refer to the shared folder or removable media where you store the installation media—on the Install from Media page in the Active Directory Domain Services Installation Wizard or by using the /ReplicationSourcePath parameter during an unattended installation.
The wizard installs AD DS using the data in the installation media, which eliminates the need to replicate every object from a partner domain controller. However, objects that were modified, added, or deleted since the installation media was created must be replicated. If the installation media was created recently, the amount of replication that is required is considerably less than the amount of replication that is required for a regular AD DS installation.

Offline Domain Join (Djoin.exe) Step-by-Step Guide

Applies To: Windows 7, Windows 8, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

This guide explains the steps that you complete to perform an offline domain join. During an offline domain join, a computer is configured to join a domain without contacting a domain controller. This guide includes the following sections:

• Offline domain join scenario overview
  
  
• Requirements for offline domain join
  
  
• Offline domain join process and Djoin.exe syntax
  
  
• Steps for performing an offline domain join
  
  

Offline domain join scenario overview

Offline domain join is a new process that computers that run Windows® 7 or Windows Server® 2008 R2 can use to join a domain without contacting a domain controller. This makes it possible to join computers to a domain in locations where there is no connectivity to a corporate network.
For example, an organization might need to deploy many virtual machines in a datacenter. Offline domain join makes it possible for the virtual machines to be joined to the domain when they initially start after the installation of the operating system. No additional restart is required to complete the domain join. This can significantly reduce the overall time that is required for wide-scale virtual-machine deployments.
A domain join establishes a trust relationship between a computer running a Windows operating system and an Active Directory® domain. This operation requires state changes to Active Directory Domain Services (AD DS) and state changes on the computer that is joining the domain. To complete a domain join in the past using previous Windows® operating systems, the computer that joined the domain had to be running and it had to have network connectivity to contact a domain controller. Offline domain join provides the following advantages over the previous requirements:

• The Active Directory state changes are completed without any network traffic to the computer.
  
• The computer state changes are completed without any network traffic to a domain controller.
  
• Each set of changes can be completed at a different time.
  

The following sections explain some of the benefits that offline domain join can provide.

Reduced total cost of ownership in data centers

Offline domain join can reduce the total cost of ownership for computers by reducing the startup time that is required for each server and by increasing the reliability of domain join operations in production environments.
Data centers commonly have a provisioning server that configures an image and then sends that image to be deployed on a production computer. The production computer is set up, joined to the domain, and restarted. If there are any problems associated with the domain join, such as network connectivity problems or problems that are associated with necessary servers that are offline, the problems have to be diagnosed and resolved at that time. In this situation, an offline domain join helps prevent problems that can arise with the communication between the production computer and a domain controller by configuring the domain join information during the setup for the production computer. The total amount of time to set up each server is reduced by eliminating the additional restart that is required to complete an online domain join.

Improved experience for performing domain joins using an RODC

In Windows Server 2008, there is a mechanism to perform domain join operations against a read-only domain controller (RODC). However, to perform a domain join operation an RODC you have to complete the following multiple steps:

1. Precreate the computer account in the directory, and set some additional attributes using scripts.
   
2. If necessary, modify the Password Replication Policy (PRP) of the RODC to allow the password for the computer that you want to join to the domain to be cached by the RODC.
   
3. Force replication of the secrets of the computer that is to join to the domain.
   
4. Communicate the password offline to the computer that is about to join to the domain.
   
5. Run a custom script that targets the RODC to complete the join.
   

When you use offline domain join, the steps for performing domain join operations against an RODC are simplified, as follows:

1. Precreate the account in AD DS.
   
2. Force replication of the secrets of the computer that is to join to the domain.
   
3. Send the relevant state information that the domain-joining computer needs to consume to a text file.
   
4. The computer consumes the information in the text file; then, when it starts it is joined to the domain.
   

Rapid enterprise deployments

By using deployment tools, such as Windows System Image Manager, you can perform an unattended domain join during an operating system installation by providing information that is relevant to the domain join in an Unattend.xml file. Using the same Unattend.xml file, you can supply the information that is necessary for the computers that run Windows 7 and Windows Server 2008 R2 to perform offline domain join.
The Unattend.xml file for Windows 7 and Windows Server 2008 R2 includes a new section to support offline domain join.

Requirements for offline domain join

To perform an offline domain join, you run commands by using a new tool named Djoin.exe. You use Djoin.exe to provision computer account data into AD DS. You also use it to insert the computer account data into the Windows directory of the destination computer, which is the computer that you want to join to the domain. The following sections explain operating system requirements and credential requirements for performing an offline domain join.
The offline domain join does not have to be completed within a specific time period. The computer account that is provisioned remains in AD DS unless an administrator intervenes. However, many organizations run scripts every 30 to 60 days to clean up stale or unused computer accounts.

Operating system requirements

You can run Djoin.exe only on computers that run Windows 7 or Windows Server 2008 R2. The computer on which you run Djoin.exe to provision computer account data into AD DS must be running Windows 7 or Windows Server 2008 R2. The computer that you want to join to the domain must also be running Windows 7 or Windows Server 2008 R2.
By default, the Djoin.exe commands target a domain controller that runs Windows Server 2008 R2. However, you can specify an optional /downlevel parameter if you want to target a domain controller that is running a version of Windows Server that is earlier than Windows Server 2008 R2.

Credential requirements

To perform an offline domain join, you must have the rights that are necessary to join workstations to the domain. Members of the Domain Admins group have these rights by default. If you are not a member of the Domain Admins group, a member of the Domain Admins group must complete one of the following actions to enable you to join workstations to the domain:

• Use Group Policy to grant you the required user rights. This method allows you to create computers in the default Computers container and in any organizational unit (OU) that is created later (if no Deny access control entries (ACEs) are added).
  
• Edit the access control list (ACL) of the default Computers container for the domain to delegate the correct permissions to you.
  
• Create an OU and edit the ACL on that OU to grant you the Create child – Allow permission. Pass the /machineOU parameter to the djoin /provision command.
  

The following procedures show how to grant the user rights with Group Policy and how to delegate the correct permissions.

Granting user rights to join workstations to the domain

You can use the Group Policy Management Console (GPMC) to modify the domain policy or create a new policy that has settings that grant the user rights to add workstations to a domain.
Membership in Domain Admins, or equivalent, is the minimum required to grant user rights. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To grant rights to join workstations to a domain

1. Click Start, click Administrative Tools, and then click Group Policy Management.
   
2. Double-click the name of the forest, double-click Domains, double-click the name of the domain in which you want to join a computer, right-click Default Domain Policy, and then click Edit.
   
3. In the console tree, double-click Computer Configuration, double-click Policies, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then double-click User Rights Assignment.
   
4. In the details pane, double-click Add workstations to domain.
   
5. Select the Define these policy settings check box, and then click Add User or Group.
   
6. Type the name of the account that you want to grant the user rights to, and then click OK twice.
   

Delegating permissions to join workstations to the domain

You can use a tool such as Ldp.exe to delegate permissions to join workstations to a domain. As a best practice, you should delegate permissions to a group, and then add users to the group or remove them as needed.
Membership in Domain Admins, or equivalent, is the minimum required to delegate permissions. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To delegate permissions to join workstations to a domain

1. Click Start, click Run, type ldp, and then click OK.
   
2. Click Connection, click Connect, and in Server type the name of a domain controller. If you are logged on to a domain controller, you can type localhost. When you are done, click OK.
   
3. Click Connection, and then click Bind. If you are logged on as a member of the Domain Admins group, click Bind as currently logged on user. If you are logged on as a different user, click Bind with credentials, and then type the name, password, and domain of an account that is a member of the Domain Admins group. Click OK.
   
4. Click View, click Tree, select DC=, and then click OK.
   
5. In the console tree, double-click DC=, right-click CN=Computers,DC=, click Advanced, click Security Descriptor, and then click OK.
   
6. Click ACE, click Add ACE, type the name of the account that you want to be able to join workstations to the domain, select the Create child check box, and then select the Inherit check box. In Object type, select computer – class (you might have to type computer to select computer – class), click OK, and then click Update.
   

Offline domain join process and Djoin.exe syntax

Run Djoin.exe at an elevated command prompt to provision the computer account metadata. When you run the provisioning command, the computer account metadata is created in a .txt file that you specify as part of the command. After you run the provisioning command, you can either run Djoin.exe again to request the computer account metadata and insert it into the Windows directory of the destination computer or you can save the computer account metadata in an Unattend.xml file and then specify the Unattend.xml file during an unattended operating system installation of the destination computer.
For more information about the NetProvisionComputerAccount function that is used to provision the computer account during an offline domain join, see NetProvisionComputerAccount Function (http://go.microsoft.com/fwlink/?LinkId=162426). For more information about the NetRequestOfflineDomainJoin function that runs locally on the destination computer, see NetRequestOfflineDomainJoin Function (http://go.microsoft.com/fwlink/?LinkId=162427).

Djoin.exe syntax

This section describes the syntax for Djoin.exe.

djoin /provision /domain  /machine  /savefile  [/machineou ] [/dcname ] [/reuse] [/downlevel] [/defpwd] [/nosearch] [/printblob] [/rootcacerts] [/certtemplate ] [/policynames ] [/policypaths ]

djoin /requestodj /loadfile  /windowspath  /localos

Note
The /rootcacerts, /certtemplate, /policynames, and /policypaths parameters are valid only on Windows Server 2012. They allow administrators to provide mobile users who never connect to corporate networks (physically or through VPN) with the ability to join a computer to the domain and configure it with DirectAccess policies.

 

Parameter	Description
/provision	Creates a computer account in AD DS.
/domain	Specifies the name of the domain to join.
/machine	Specifies the name of the computer that you want to join to the domain.
/machineou	Specifies the name of the organizational unit (OU) in which you want the computer account to be created. By default, the computer account is created in the Computers container. This parameter is ignored if /reuse is specified.
/dcname	Specifies the name of a specific domain controller that will create the computer account. If you do not specify a domain controller, the domain controller Locator (DC Locator) process is used to select a domain controller.
/reuse	Specifies the reuse of any existing computer account. The password for the computer account will be reset.
/downlevel	Supports the use of a domain controller that runs a version of Windows Server that is earlier than Windows Server 2008 R2.
/savefile	Saves provisioning data to a file.
/defpwd	Uses the default machine account password (not recommended).
/nosearch	Skips account conflict detention. Requires the /DCName parameter.
/printblob	Return a base64-encoded metadata blob for an answer file.
/rootcacerts This parameter is only available on Windows Server 2012.	Optionally include root Certificate Authority certificates.
/certtemplate This parameter is only available on Windows Server 2012.	Optional of machine certificate template. Includes root Certificate Authority certificates.
/policynames This parameter is only available on Windows Server 2012.	Optional semicolon-separated list of Group Policy object (GPO) names. Each name is the displayName of the GPO in AD DS.
/policypaths This parameter is only available on Windows Server 2012.	Optional semicolon-separated list of policy paths. Each path is a path to a registry.pol file. GPOs store registry-based configuration settings in registry.pol files. To include registry-based configuration settings in the blob data, specify the path and file name using any of the following formats: /POLICYPATHS mypolicy.xyz /POLICYPATHS .\mypolicy2.xyz /POLICYPATHS c:\tmp\mypolicy3.xyz /POLICYPATHS \\server\share\mypolicy4.xyz /POLICYPATHS mypolicy.xyz;.\mypolicy2.xyz;c:\tmp\mypolicy3.xyz;\\server\share\mypolicy4.xyz For more information about registry.pol files, see Registry.pol.
/NetBIOS Applies to computers that run versions of Windows beginning with Windows Server 2012 R2 and Windows 8.1.	Optional NetBIOS name of the computer joining the domain.
/psite Applies to computers that run versions of Windows beginning with Windows Server 2012 R2 and Windows 8.1.	Optional name of the persistent site to put the computer joining the domain in.
/dsite Applies to computers that run versions of Windows beginning with Windows Server 2012 R2 and Windows 8.1.	Optional name of the dynamic site to initially put the computer joining the domain in.
/primarydns Applies to computers that run versions of Windows beginning with Windows Server 2012 R2 and Windows 8.1.	Optional name of primary DNS domain of the computer joining the domain.
/requestodj	Requests an offline domain join at the next start.
/Loadfile	Specifies the output from a previous provisioning command.
/windowspath	Specifies the path to the Windows directory of the offline image. If you are using the /localos parameter, specify %systemroot% or %windir% as the value of the /windowspath parameter.
/localos	Targets the local operating system installation, instead of an offline image, with the domain join information. If you use this parameter, the value that you specify for /windowspath should be %systemroot% or %windir%. Run this parameter only on a destination computer that you want to join to the domain. This parameter is blocked from being run on a domain controller. Because this parameter injects the blob data into the locally running operating system image, you must restart the computer to complete the domain join operation, as you must also do for an online domain join.

Steps for performing an offline domain join

The offline domain join process includes the following steps:

1. Run the djoin.exe /provision command to create computer account metadata for the destination computer (the computer that you want to join to the domain). As part of this command, you must specify the name of the domain that you want the computer to join.
   
2. Run the djoin.exe /requestODJ command to insert the computer account metadata into the Windows directory of the destination computer.
   
3. When you start the destination computer, either as a virtual machine or after a complete operating system installation, the computer will be joined to the domain that you specify.
   

The following sections explain different ways for you to perform these steps. You can use the Windows Server 2008 Hyper-V™ virtualization feature to create virtual machines, you can use different physical computers, or you can run an unattended setup to perform an operating system installation on the destination computer. In any of these cases, the computer where you run the provisioning command and the computer where you run the request command must be running Windows 7 or Windows Server 2008 R2.
You can also perform these steps using a dual-boot computer. In this case, follow the steps to perform an offline domain join using Hyper-V, but substitute the virtual machines with physical partitions that are running Windows 7 or Windows Server 2008 R2.

Performing an offline domain join by using Hyper-V

To perform an offline domain join using Hyper-V, create the following virtual machines:

• VM1: A domain controller that runs Windows Server 2008 R2.
  
• VM2: A domain-joined computer that runs Windows 7 or Windows Server 2008 R2. This computer will serve as a provisioning server on which you can run the djoin /provision command. As an alternative, you can complete these steps without using this virtual machine by running the djoin /provision command on the domain controller that is VM1. This additional VM2 is shown to provide a more realistic example of how computers are provisioned in production environments, where a domain-joined computer is used typically as a provisioning server.
  
• VM3: A computer that runs Windows 7 or Windows Server 2008 R2 that you want to join to the domain.
  

Note
Do not use differencing disks from the same parent virtual hard disk (VHD) for these virtual machines. The differencing disk will not start correctly after you complete the steps to perform the offline domain join. You should also not use copies of the same VHD, because it will cause one virtual machine to be disabled when you try to mount it from the other virtual machine.

Complete the following steps to perform the offline domain join:

1. Log on to VM2 as a user who has rights to add workstations to a domain.
   
2. Type the following command to provision the destination computer:
   
   
   djoin /provision /domain  /machine  /savefile 
   

   Security Note

   The base64-encoded metadata blob that is created by the provisioning command contains very sensitive data. It should be treated just as securely as a plaintext password. The blob contains the machine account password and other information about the domain, including the domain name, the name of a domain controller, the security ID (SID) of the domain, and so on. If the blob is being transported physically or over the network, care must be taken to transport it securely.

3. Shut down VM3 and VM2, and then mount VM3 from VM2.
   
   To do this in Hyper-V, right-click VM2, and then click Settings. Click IDE Controller, and then click Add. Select Virtual hard disk (.vhd) file, click Browse, navigate to the location of the .vhd file for VM3, click Open, and then click OK.
   
4. Restart VM2, and then use Windows Explorer to locate the drive where VM3 is mounted. At an elevated command prompt, type the following command to request the offline domain join data:
   
   
   djoin /requestODJ /loadfile  /windowspath 
   

5. Shut down VM2, and then unmount VM3 from VM2. To do this in Hyper-V, right-click VM2, and then click Settings. Click the integrated device electronics (IDE) controller that corresponds to VM3, and then click Remove.
   
6. Start VM3. The computer will be joined to the domain after it starts.
   

If you experience any problems running the Djoin.exe commands, you can view the log file on VM2 at %windir%\debug\netsetup.log for more information.

Performing an offline domain join using different physical computers

To perform an offline domain join using physical computers, you can complete the following steps. The best practice in this case is to have one domain controller, one domain-joined computer to use as a provisioning server, and one client computer that you want to join to the domain.

1. On the provisioning server, open an elevated command prompt. To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
   
2. Type the following command to provision the computer account:
   
   
   djoin /provision /domain  /machine  /savefile blob.txt
   

3. Copy the blob.txt file to the client computer.
   
4. On the client computer, open an elevated command prompt, and then type the following command to request the domain join:
   
   
   djoin /requestODJ /loadfile blob.txt /windowspath %SystemRoot% /localos
   

   Caution
   You cannot run this command with the /localos parameter on a domain controller.

5. Reboot the client computer. The computer will be joined to the domain.
   

Performing an offline domain join by using an unattended operating system installation

To perform an offline domain join during an operating system installation, you must first run Djoin.exe to provision the computer account metadata. Then, you create an Unattend.xml file and include a new section in it for the offline domain join data. In the new section, you can insert the computer account metadata.
The component name for the new section is Microsoft-Windows-UnattendJoin/Identification/Provisioning, and it includes the following structure:

• 
  
• 
  
•      
  
•           
  
•                Base64Encoded Blob
  
•           

     

You have to insert the computer account metadata within the and tags. After you create the Unattend.xml file, start the computer that you want to join to the domain in Safe Mode or start the computer in Windows Preinstallation Environment (Windows PE), and then run the setup command with an answer file, as shown in the following example:

setup /unattend:

See Also

Other Resources

NetProvisionComputerAccount Function
NetRequestOfflineDomainJoin Function

Registry Extension

Group Policy includes the Registry preference extension. For computers or users, this extension allows you to:

• Copy multiple registry settings from a computer and apply those settings to other computers.
  
• Create, replace, or delete an individual registry value.
  
• Create an empty key, delete a key, or delete all values and subkeys in a key.
  
• Create collections (folders) to organize Registry preference items in the Group Policy Management Console, and so you can apply the same targeting to multiple Registry items.
  
• Create collections in the Group Policy Management Console that mirror the structure of keys in the registry on a selected computer.
  

Getting started

You can create and configure Registry preference items for any domain-based Group Policy object (GPO). You configure the settings by editing a GPO using the Group Policy Management Console. When editing a GPO, you can find this preference extension at the following location:
Computer Configuration or User Configuration
   └ Preferences
      └ Windows Settings
         └ Registry
For information about how to use this extension to create and configure a preference item, see the following topics:

• Create Multiple Registry Items Using the Registry Wizard
  
  
• Configure a Registry Item
  
  
• Configure Common Options
  
  
• Organize Registry Items               

Overview of Authorization Manager

Role-based access control enables you to assign users to roles and to keep track of what permissions have been given to each role. You can also apply very specific control by using scripts called authorization rules. Authorization rules enable you to control the relationship between access control and the structure of your organization.
Authorization Manager can help provide effective control of access to resources in many situations. Generally, two categories of roles often benefit from role-based administration: user authorization roles and computer configuration roles.

• User authorization roles are based on a user's job function. You can use authorization roles to authorize access, to delegate administrative privileges, or to manage interaction with computer-based resources. For example, you might define a Treasurer role that includes the right to authorize expenditures and audit account transactions.
  
• Computer configuration roles are based on a computer's function. You can use computer configuration roles to select features that you want to install, to enable services, and to select options. For example, computer configuration roles for servers might be defined for Web servers, domain controllers, file servers, and custom server configurations that are appropriate to your organization.
  

Using developer mode and administrator mode in Authorization Manager

With Authorization Manager, you can use the following two modes:

• Developer mode. In developer mode, you can create, deploy, and maintain applications. You have unrestricted access to all Authorization Manager features.
  
• Administrator mode. This is the default mode. In administrator mode, you can deploy and maintain applications. You have access to all Authorization Manager features, but you cannot create new applications or define operations.
  

Commonly, Authorization Manager is used by custom applications written for a specific purpose in your environment. These applications usually create, manage, and use an authorization store by calling the Authorization Manager application programming interfaces (APIs). In that case, you do not need to use developer mode. For more information about using Authorization Manager programmatically, see Resources for Authorization Manager.
When you use developer mode, it is recommended that you run Authorization Manager in developer mode only until the authorization store, application, and other necessary objects are created and configured. After you initially set up Authorization Manager, run Authorization Manager in administrator mode. For more information about using developer or administrator mode, see Set Authorization Manager Options.

Comparing Authorization Manager to other management tools

You can use Authorization Manager to implement multiple configuration and permission changes at once. Other management tools available with this version of Windows can also be used to configure access permissions, sometimes in ways comparable to Authorization Manager. These include:

• Access control lists. Access control lists (ACLs) on the Security properties tab can be used to manage access control policy for objects stored in Active Directory Domain Services (AD DS), Active Directory Lightweight Directory Services (AD LDS), and Windows objects. Authorization Manager differs from the Security properties tab by letting you base your access control on roles (usually based on particular job tasks), not just on group membership, and by tracking the permissions that have been granted.
  
• Delegation of Control Wizard. The Delegation of Control Wizard also sets multiple permissions automatically; however, unlike Authorization Manager, it does not provide a method to track or remove permissions that have been granted.
  

Additional references

• Resources for Authorization Manager
  
  
• What's New in Authorization Manager
  
  
• Checklist: Before You Start Using Authorization Manager

Enable and Configure Shadow Copies of Shared Folders

Applies To: Windows Server 2008 R2, Windows Server 2012

If you enable Shadow Copies of Shared Folders on a volume using the default values, a task will be scheduled to create shadow copies at 7:00 A.M.. The default storage area will be on the same volume, and its size will be 10 percent of the available space.
You can only enable Shadow Copies of Shared Folders on a per-volume basis—that is, you cannot select specific shared folders and files on a volume to be copied or not copied.

To enable and configure Shadow Copies of Shared Folders

1. Click Start , point to Administrative Tools , and then click Computer Management .
   
2. In the console tree, right-click Shared Folders , click All Tasks , and then click Configure Shadow Copies .
   
3. In Select a volume , click the volume that you want to enable Shadow Copies of Shared Folders for, and then click Enable .
   
4. You will see an alert that Windows will create a shadow copy now with the current settings and that the settings might not be appropriate for servers with high I/O loads. Click Yes if you want to continue or No if you want to select a different volume or settings.
   
5. To make changes to the default schedule and storage area, click Settings .
   

Additional references

• Best Practices for Shadow Copies of Shared Folders
  
  
• Troubleshooting Shadow Copies of Shared Folders
  
  
• Shadow Copies of Shared Folders                 

Best Practices for Shadow Copies of Shared Folders

Applies To: Windows Server 2008 R2, Windows Server 2012

We recommend that you consider the following best practices when you work with Shadow Copies of Shared Folders.

Use a separate volume on another disk as the storage area for shadow copies.

• Select a storage area on a disk that is not being shadow copied. Using a separate volume on another disk eliminates the possibility that high I/O load will cause shadow copies to be deleted and provides better performance. This is the recommended configuration for heavily used file servers. For failover clusters, this configuration also requires that the original volume and storage volume belong to the same cluster resource group.
  

If you are using failover clusters, two volumes on the same disk cannot be associated for diff area storage.

• This is because the cluster manages the disk for online and offline operations, but the Volume Shadow Copy Service (VSS) needs to have the diff area and original volumes brought offline or online in a specific order. Instead, the storage volume and the original volume need to be the same volume, or they need to be on separate physical disks.
  

Consider how your clients will use a shared resource before you enable Shadow Copies of Shared Folders and set scheduling options.

• Adjust the shadow copy schedule to fit the work patterns of your clients.
  

Do not enable shadow copies on volumes that use mount points.

• The mounted drive will not be included when shadow copies are created. Enable shadow copies only on volumes without mount points or when you do not want the shared resources on the mounted volume to be shadow copied. Alternatively, you can explicitly include the mounted volume in the schedule for shadow copy creation. (For previous versions of a file to be available, the volume must have a drive letter assigned.)
  

Perform regular backups of your file server.

• Shadow Copies of Shared Folders is not a replacement for performing regular backups. Use a backup utility, such as Windows Server Backup in Windows Server 2008 or Windows Server 2008 R2, in coordination with Shadow Copies of Shared Folders as your strategy for data protection.
  

Do not schedule copies to occur more often than once per hour.

• The default schedule for creating shadow copies is at 7:00 A.M., Monday through Friday. If you decide that you need copies to be created more often, verify that you have allotted enough storage space and that you do not create copies so often that server performance degrades. There is also an upper limit of 64 copies per volume that can be stored before the oldest copy is deleted. If shadow copies are created too often, this limit might be reached very quickly, and older copies could be lost at a rapid rate.
  

Before deleting a volume that is being shadow copied, delete the scheduled task for creating shadow copies.

• If the volume is deleted without deleting the shadow copy task, the scheduled task will fail and an Event ID: 7001 error will be written to the event log. Delete the task before deleting the volume to avoid filling the event log with these errors. To manually delete the scheduled task, click Start , point to Administrative Tools , and then click Task Scheduler . In Task Scheduler, click Task Scheduler Library , right-click the task to create shadow copies, and then click Delete .
  

Use an allocation unit size of 16 kilobytes (KB) or larger when formatting a source volume on which Shadow Copies of Shared Folders will be enabled.

• If you plan to defragment the source volume on which Shadow Copies of Shared Folders is enabled, we recommend that you set the cluster allocation unit size to be 16 KB or larger when you initially format the source volume. If you do not, the number of changes caused by defragmentation can cause previous versions of files to be deleted.
  
• If you require NTFS file compression on the source volume, you cannot use an allocation unit size larger than 4 KB. In this case, when you defragment a volume that is very fragmented, you may lose older shadow copies faster than expected.
  

After backing up a volume that contains shadow copies, do not restore the volume to a different volume on the same computer

After backing up a volume that contains shadow copies, do not restore the volume to a different volume on the same computer as this will leave multiple snapshots with the same Snapshot ID on the system and will cause unpredictable results when performing a shadow copy revert.
You can restore the volume to the original volume on the same computer; you can restore the volume to a different volume on a different computer, or you can restore file and folders to any location on the same computer.

Additional references

• Enable and Configure Shadow Copies of Shared Folders
  
  
• Shadow Copies of Shared Folders
  
  
• Troubleshooting Shadow Copies of Shared Folders                 

How to Configure a Clustered Storage Space in Windows Server 2012

Prerequisites

•          A minimum of three physical drives, with at least 4 gigabytes (GB) capacity each, are required to create a storage pool in a Failover Cluster.
•          The clustered storage pool MUST be comprised of Serial Attached SCSI (SAS) connected physical disks. Layering any form of storage subsystem, whether an internal RAID card or an external RAID box, regardless of being directly connected or connected via a storage fabric, is not supported.
•          All physical disks used to create a clustered pool must pass the Failover Cluster validation tests. To run cluster validation tests:
  • Open the Failover Cluster Manager interface (cluadmin.msc) and select the Validate Cluster option.

•          Clustered storage spaces must use fixed provisioning.
•          Simple and mirror storage spaces are supported for use in Failover Cluster. Parity Spaces are not supported.
•          The physical disks used for a clustered pool must be dedicated to the pool. Boot disks should not be added to a clustered pool nor should a physical disk be shared among multiple clustered pools.
•          Storage spaces formatted with ReFS cannot be added to the Cluster Shared Volume (CSV).

Steps to configure using the Failover Cluster Manager

1.       Add the File Services Role and the File Services Role Administration Tools  to all nodes in the Failover Cluster
2.       Open the Failover Cluster Manager interface (cluadmin.msc)
3.       In the left-hand pane, expand Storage. Right-click on Pools and select New Storage Pool. This will start the New Storage Pool Wizard

4.       Specify a Name for the Storage Pool and choose the Storage Subsystem that is available to the cluster and click Next

5.       Select the Physical Disks (a minimum of three with minimum capacity 4GB each and bus type SAS) for the storage pool and confirm the creation of the pool. The pool will be added to the cluster and brought Online, once created.

6.       The next step is to create a Virtual Disk (storage space) that will be associated with a storage pool. In the Failover Cluster Manager, select the storage pool that will be supporting the Virtual Disk. Right-click and choose New Virtual Disk

7.       This initiates the New Virtual Disk Wizard. Select the server and storage pool for the virtual disk and click Next.  Note that the cluster node hosting the storage pool will be listed.

8.       Provide a name and description for the virtual disk and click Next

9.       Specify the desired Storage Layout (Simple or Mirror; Parity is not supported in a Failover Cluster) and click Next
Note: I/O operations to a CSV mirror space are redirected at the block level through the CSV coordinator node. This may result in different performance characteristics for I/O to the storage, compared to a simple space.

10.   Specify the size of the virtual disk and click Next. After you confirm your selection, the virtual disk is created. The New Volume Wizard is launched if you do not uncheck this option on the confirmation page.

11.   The correct Disk and the Server to provision the disk to should be selected for you. Verify this selection and click Next.

12.   Specify the size of the volume and click Next

13.   Optionally assign a drive letter to the volume and click Next
 
14.   Select the file system settings and click Next and confirm the volume settings. The new volume will be created on the virtual disk and will be added to the Failover Cluster.
Note: The NTFS File System should be selected if the volume is to be added to Cluster Shared Volumes.
 
15.   Your clustered storage space can now be used to host clustered workloads. You can also see the properties of the clustered storage space and the clustered pool that contains it, from the Failover Cluster Manager.
 

Steps to configure using Windows PowerShell®

Open a Windows PowerShell® console and run the following steps:
1.       Create a new pool
a.  Select physical disks to add to the pool
$phydisk = Get-PhysicalDisk –CanPool $true | Where BusType -eq "SAS”
b.  Obtain the storage subsystem for the pool
$stsubsys = Get-StorageSubsystem
c.       Create the new storage pool
$pool = New-StoragePool -FriendlyName TestPool -StorageSubsystemFriendlyName $stsubsys.FriendlyName -PhysicalDisks $phydisk -ProvisioningTypeDefault Fixed
d.      Optionally add an additional disk as a HotSpare
$hotSpareDisk = Get-PhysicalDisk –CanPool $true |Out-GridView -PassThru
Add-PhysicalDisk -StoragePoolFriendlyName TestPool -PhysicalDisks $hotSpareDisk -Usage HotSpare

2.        Now create a Storage Space in the pool created in the previous step
a.  $newSpace = New-VirtualDisk –StoragePoolFriendlyName TestPool –FriendlyName space1 -Size (1GB)  -ResiliencySettingName Mirror   

3.       Initialize, partition and format the Storage Space created
a.  $spaceDisk = $newSpace | Get-Disk
b.  Initialize-Disk -Number $spaceDisk.Number -PartitionStyle GPT
c.  $partition = New-Partition -DiskNumber $spaceDisk.Number -DriveLetter $driveletter -size $spaceDisk.LargestFreeExtent
d.  Format-Volume -Partition $partition -FileSystem NTFS

4.       Add the Storage Space created to the Cluster
a.  $space = Get-VirtualDisk -FriendlyName space1              
b.   Add-ClusterDisk $space

Note:

• Clustered Spaces can also be created using the Server Manager:

• You can find a full end to end Windows PowerShell® sample on setting up a file server cluster with Storage Spaces here.

Troubleshooting tips:
If you come across any of the following errors while attempting to add a storage pool to the cluster please review the Prerequisites section at the beginning of this blog to determine which requirement was not met:

Failed to add storage pool to cluster – {XXXXXXX-XXXX-XXXX-XXXX-XXXXXXX}

No storage pool suitable for cluster was found.