Alexander’s Blog

As you may know, SharePoint deployments are managed at the farm level. Therefore, users can install additional SharePoint farms in your environment without your permission. Obviously, you don’t want SharePoint farms popping up on your network without your knowledge and approval. You want to make sure that new deployments conform to your company’s standards. So how do you stop unauthorized SharePoint deployments? Use the following methods to block or track SharePoint installations.

How to Block SharePoint Installations

To disable the installation of SharePoint Server and related products, configure the following registry key using Group Policy in Active Directory directory services:
HKLM\Software\Policies\Microsoft\Shared Tools\Web Server Extensions\14.0\ SharePoint\DWORD DisableInstall

Setting the DWORD value DisableInstall=00000001 will block the installation. Once you have configured this setting, when a user tries to install SharePoint Server, he/she will get the following error message:

SharePoint installation is blocked in your organization. Please contact your network administrator for more details.

How to Track SharePoint Installations

You can also track SharePoint installations in your organization by using the Active Directory Domain Services (AD DS) marker. Here’s a description from Microsoft TechNet on how the AD DS marker works.

“An Active Directory Domain Services (AD DS) Marker called Service Connection Point identifies the SharePoint 2010 Products servers in an organization. To use this marker, create a container in AD DS and set the permissions for the container before you install any SharePoint 2010 Products in the environment. Then, when you or another user in your domain runs the SharePoint Products Configuration Wizard as part of installing SharePoint Server 2010, this marker is set, and can be tracked by using AD DS. You must set this marker for each domain that you have in your organization if you want to track installations in all domains. This marker is removed from AD DS when the last server is removed from a farm. You can also set the marker by using Windows PowerShell. The marker contains the URL for the Application Discovery and Load Balancer Service (also known as the topology service application) for the server farm.

You have to grant permission to write to this container to any user accounts or domain accounts that could run the SharePoint Products Configuration Wizard. If the account does not have permission to write to this container, the following warning will appear in the log file for the SharePoint Products Configuration Wizard:

Failed to add the service connection point for this farm

Unable to create a Service Connection Point in the current Active Directory domain. Verify that the SharePoint container exists in the current domain and that you have rights to write to it.”

For more information on how to create the container in Active Directory and set the permissions using Active Directory Service Interfaces (ADSI) Edit, check out this article.

The other day I noticed that my Windows Server 2012 Datacenter was not accepting replication requests. In fact, it was rejecting both inbound and outbound replication. The way I discovered the problem was that I was unable to connect to a couple of Windows Server 8 Enterprise computers that I just added to the network in Remote Desktop Connection Manager v2.2. I was getting the DNS error. I first tried to flush the DNS cache (IPconfig /flushdns) at the command prompt and then tried a few other things. When I looked at one Domain Controller (DC) it had the DNS records of the new computers but the other one didn’t. The DNS servers on both these DCs were Active Directory-integrated. I tried to manually force the replication and discovered that Windows Server 2012 wasn’t accepting replication. This is where I started to troubleshoot the replication problem.

Troubleshooting

I ran DCDIAG on the problem DC using the following switches.

/v: Verbose – Print extended information

/c: Comprehensive, runs all tests, including non-default tests but excluding DcPromo and RegisterInDNS.

/s: Use <Directory Server> as Home Server. Ignored for DcPromo and RegisterInDns tests which can only be run locally.

I piped all the results into a text file because it is easy to read the results in a text file that I can also print out. Here’s the syntax I used.

dcdiag /v /c /s:[Directory Server] > c:\temp\dcdiag_2012_12_24.txt

where Directory Server is the name of the server that is having problems. For example:

dcdiag /v /c /s:MyDC1 > c:\temp\dcdiag_2012_12_24.txt

Evaluating the Results

To evaluate the results, first I skimmed through the results looking for any obvious errors. Then I did a search for the word “failed” to narrow down my search and focus on specific failures. I discovered several things. First of all MyDC1 had failed the Advertising test.

Testing server: Default-First-Site-Name\MyDC1

Starting test: Advertising

Warning: DsGetDcName returned information for \\MyDC2.contoso.com,

when we were trying to reach MyDC1.

SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.

……………………. MyDC1 failed test Advertising

In addition, the DC also failed the Replications test. This was not a surprise because I knew that the DC is rejecting requests for replication. I just didn’t know why.

Starting test: Replications

* Replications Check
[Replications Check,Replications Check] Inbound replication is disabled.

To correct, run “repadmin /options WS12DC1 -DISABLE_INBOUND_REPL”

[Replications Check,MyDC1] Outbound replication is disabled.

To correct, run “repadmin /options MyDC1 -DISABLE_OUTBOUND_REPL”

……………………. MyDC1 failed test Replications

As the results report clearly showed me both inbound replication and outbound replication were disabled. The report also suggested that I needed to run the RepAdmin command to enable them.

The third thing I noticed was that the time service on the DC has stopped and the NetLogon service was paused.

Starting test: Services

* Checking Service: EventSystem
* Checking Service: RpcSs
* Checking Service: NTDS
* Checking Service: DnsCache
* Checking Service: NtFrs
* Checking Service: IsmServ
* Checking Service: kdc
* Checking Service: SamSs
* Checking Service: LanmanServer
* Checking Service: LanmanWorkstation
* Checking Service: w32time
w32time Service is stopped on [MyDC1]

* Checking Service: NETLOGON
NETLOGON Service is paused on [MyDC1]

……………………. MyDC1 failed test Services

The NetLogon service is a crucial service. Not only it verifies NTLM logon requests, it also registers, authenticates, and locates domain controllers. Windows Time service is also important because it maintains date and time synchronization on all clients and servers in the network.

Solution: Enable Inbound & Outbound Replication

I followed the instructions in the DCDIAG report and ran the following command at the command prompt.

C:\Windows\system32>repadmin /options MyDC1 -DISABLE_INBOUND_REPL
Current DSA Options: IS_GC DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
New DSA Options: IS_GC DISABLE_OUTBOUND_REPL

Notice the current DSA Options after I ran the command. Both inbound and outbound replications were disabled. After I ran this command now only the outbound replication is disabled, which means the inbound replication is now enabled. I then ran the second command to enable the outbound replication.

C:\Windows\system32>repadmin /options MyDC1 -DISABLE_OUTBOUND_REPL
Current DSA Options: IS_GC DISABLE_OUTBOUND_REPL
New DSA Options: IS_GC

Now both the inbound replication and the outbound replication are enabled.

Solution: Start Netlogon and Windows Time Service

I enabled the Netlogon and Windows Time service in services console (services.msc). At this point I went to Active Directory Sites & Services console and manually replicated from MyDC2 to MyDC1 and it successfully replicated all the objects. I ran the DCDIAG report once again to verify that there were no errors and everything looked fine.

Additional Resources

1. I found this article that has some useful information: Troubleshooting AD Replication error 8456 or 8457: “The source | destination server is currently rejecting replication requests.
2. There are some other utilities like DNSLint that can be useful in troubleshooting DNS name resolution issues. You can download DNSLint from Microsoft here.

In SharePoint Server 2010, User Profile Synchronization (UPS) service allows you to synchronize your user profiles between Active Directory and SharePoint. Users can add their photos to their profile in SharePoint when they are on their own Web site, called MySite. Here’s how you can see where the pictures are located.

1. To view these photos delete everything in the URL after the domain name and add /user photos/. For example, http://mysite.contoso.com/user photos/.

2. You will notice that there is a folder in the library called Profile Pictures. Click this folder and you will see three photos for each profile.

3. There is a large (144 x 144), medium (96 x 96) and small (32 x 32) thumbnail for each picture labeled as LThumb, MThumb, and SThumb.

On a separate but somewhat related topic, the images in user profiles are different than the images that can be stored in the Exchange 2010 Global Address List (GAL). Active Directory has a thumbnailPhoto attribute that works with Exchange 2010 GAL to display the photo in Outlook 2010. Even without Exchange 2010, you can add images to your own Contacts list in Outlook 2010 directly. When you receive e-mails from people in your contacts list, you will see there photos in the e-mail message.

Microsoft has made some major changes to its server operating system in Windows Server 2012, which is in beta at the time of writing. One of the new features in Active Directory Domain Services (AD DS) in Windows Server 2012 is the ability to clone a virtualized Domain Controller (DC). In this article, I will explain how cloning works, describe the XML files that are required for cloning, and walk you through step-by-step process of cloning a virtualized DC.

Remember all the pain you had to go through to deploy a virtualized DC replicas in the previous versions of Windows Servers? All the messing around with sysprep images, promoting the DC manually and then going through all the post-configuration process is now the thing of the past because in Windows Server 2012 you can create replicas of virtualized DCs by cloning the existing DCs. Simply copy the virtual hard disk (VHD) of a virtualized DC, insert a configuration file, and create a new virtualized DC pointing to the copied VHD. Imagine how much time you will be saving. Okay, you do have to do some work for the first time so I don’t want to give you the impression that you are going to wave your magic wand and everything will take place magically. However, the steps to clone a virtualized DC are not as complicated any more.

According to Microsoft, the requirements for virtualized DC cloning are as follows:

1. Windows Server 2012 virtual DC hosted on VM-Generation-ID-aware hypervisor platforms. This DC will act as source for the cloning operation.
2. In order to authorize the cloning operation, the PDC operations master FSMO role must be running on a Windows Sever 2012 but doesn’t have to be running on a hypervisor.
3. Source DC must be authorized for cloning through permission on domain – “Allow DC to create a clone of itself.”
4. You must create the DCCloneConfig.XML file on the clone DC and copy it in the directory where NTDS.DIT file is located.
5. Common Windows Server 2012 services, such as DNS, FRS, and DFSR, that are co-located with DCs are supported.
6. Additional services and scheduled tasks installed on the clone-source must be added to an admin-extensible whitelist,

The Cloning Process

Here’s how the cloning process works.

1. First make sure that you meet the above requirements.
2. Make a copy of an existing virtual DC’s VHD or its VM.
3. Authorize the DC for cloning in AD DS.
4. Create DCCloneConfig.XML file in the directory where NTDS.DIT file is located. By default, it’s located in %windir%/NTDS folder.
5. The clone DC uses two triggers to detect that it is a copy of another DC:
   a) The VM-Generation ID provided by the virtual machine is different from the one that’s stored in the Directory Information Tree (DIT).
   b) There is a DCCloneConfig.xml present either in the directory where the DIT is located or in the root of a removable drive, such as a DVD drive.
6. Once the DC identifies that it’s a clone by detecting that the VM-Generation ID is different on the imported or new VM and there’s a DCCloneConfig.xml file, it goes through the process of cloning itself as a DC.
7. The clone DC contacts a Windows Server 2012 PDC emulator. It uses the security context of the source DC to accomplish this.
8. The PDC emulator verifies that the requesting DC is authorized to be cloned and it creates the necessary objects that will be used to identify it as a clone. These objects include a SID, account and password.
9. The clone DC then creates the AD DS database files and it also calls the selected sysprep providers to clean up the machine state. The list of components for which the clone calls sysprep providers is available in the DefaultDCCloneAllowList.xml file located in %windir%\system32.

Understanding the XML Files for Cloning

There are three xml files used by the cloning process. Let’s take a closer look at them.

1. DefaultDCCloneAllowList.xml – This file exists by default in the %windir%\system32 folder on all Windows Server 2012 DCs . It lists the services and installed programs that can be cloned by default. You should never mess with this file at all. There is nothing in this file that you would want to manually change so leave it alone or else your cloning will fail.
2. DCCloneConfig.xml – This file is also required to clone a virtualized DC. This file should be present in %windir%\NTDS folder, or wherever your DIT file exists. It can also be present in the root of your DVD drive. This file not only helps initiate cloning it also contains configuration information for the clone DC, such as its name, site and IP settings. You need to make sure that you update the file with these parameters otherwise the system will generate these settings for you. I don’t want the system to make up name and IP address for my DC, neither should you. You can find a sample DCCloneConfig.xml file at %windir%\system32\SampleDCCloneConfig.xml.

   

3. CustomDCCloneAllowList.xml – This file should be present in %windir%\NTDS folder, or wherever your DIT file exists. You may have services running on your source DC that are not listed in the DefaultDCCloneAllowList.xml file. Those services should be listed in this CustomDCCloneAllowList.xml file. To get a list of these services or applications that are not listed in the in the DefaultDCCloneAllowList.xml file, use the Get-ADDCCloningExcludedApplicationList cmdlet. If you run this cmdlet and it returns any output, you must list those items in this file after evaluating that they can be safely cloned or remove them from the source DC cloning to successfully complete. For more information, visit Microsoft’s Web site here.WARNING! If the applications are not cloneable, make sure you remove them from the source DC, otherwise the cloning will fail.

   

Step-By-Step Process of Cloning a DC

Now that you have a better understanding of the cloning process and the different files that are used for cloning, let’s walk through the step-by-step procedure of cloning a virtualized DC. There are 5 major steps to clone a virtualized DC.

Step 1: Make sure you meet the prerequisites.
Step 2: Grant the source virtualized DC the permission to be cloned.
Step 3: Create DCCloneConfig.xml file.
Step 4: Run Get-ADDCCloningExcludedApplicationList cmdlet.
Step 5: Export the VM of the source virtualized DC and then import it.

Step 1 – Meet the Prerequisites

1. The source DC (the DC that will be used for cloning) and the destination DC (the new DC that will become the clone of the source DC) must be running on Windows Server 2012 with Hyper-V role installed and they must be in the same domain.
2. The source DC must be a virtualized DC running in Hyper-V environment on a Windows Server 2012.
3. There needs to be a Windows Server 2012 DC (virtual or physical) that is running the PDC emulator FSMO role on your network. It is not necessary that this role is running on the source or destination DC, it needs to be running on a Windows Server 2012 DC somewhere on the network.
4. The virtual network switches on both Hyper-V hosts should have the same name. In other words, if one is named DEVNET then the other must also be named DEVNET.
5. The processors on the source and destination DCs don’t need to be the same but if they are different than follow this procedure. Right-click the source DC’s in Hyper-V Manager and click Settings. Click Processor, Compatibility and select Migrate to a physical computer with a different processor version. This option will be grayed out if your virtualized DC is running.

Step 2 – Grant Source Virtualized DC Proper Permissions

1. Open Active Directory Administrative Center (ADAC).
2. Go to Domain Controllers OU.
3. Right-click the DC that will be cloned and select Add to group, under the Enter the object name to select type Clonable Domain Controllers and then click OK. Clonable Domain Controllers is a builtin group in Windows Server 2012. This step will ensure that the source virtualized DC has the proper permissions to be cloned.

   

Step 3 – Create DCCloneConfig.xml File

1. Copy the SampleDCCloneConfig.xml located in the %windir%\system32 folder from source DC to the %windir%\NTDS folder and rename it to DCCloneConfig.xml.
2. Update the DCCloneConfig.xml file as necessary. The information you need to enter is described below.ComputerName – This should be the name of the new cloned DC, i.e. the destination DC. Do not enter the name of the source DC here.
   SiteName – Enter the site name for the destination DC
   Under IPv4Settings element:
   Address – Enter a static IPv4 address
   SubnetMask – Enter the IPv4 subnet mask
   DefaultGateway – Enter the IPv4 default gateway
   DNSResolver – Enter the IPv4 DNS server
   DNSResolver – If you have an alternate DNS server you can enter it here
   Under IPv6Settings element:
   DNSResolver – Enter the IPv6 DNS server
   DNSResolver – If you have an alternate DNS server you can enter it here

Step 4 – Run Get-ADDCCloningExcludedApplicationList Cmdlet

1. On the source DC, click Server Manager, Tools, Active Directory Module for Windows PowerShell, and then type the following command:
   Get-ADDCCloningExcludedApplicationList
2. If you see a list of returned services and/or installed programs then you need to work with the vendor of the service or program to ensure that they can be cloned. If there are any items that cannot be cloned, you must remove them from the source DC or the cloning will fail.
3. Assuming that you have applications that can be cloned, create a file called CustomDCCloneAllowList.xml in the %windir%\NTDS folder on the source DC where the DIT file resides and and list these services or installed programs in the appropriate element tags in the CustomDCCloneAllowList.xml file (see sample file earlier in this article in the section Understanding the XML Files for Cloning). Just enter the Service or Program’s name listed in the cmdlet’s output within the <Type> tags.

Step 5 – Export and then Import the Source Virtualized DC

The final step is to export the VM of the source virtualized DC and then import it. Here’s how.

1. Ensure that the source virtualized DC has been shutdown.
2. Delete all the snapshots to merge all the AVHD files into a single VHD file for the source virtualized DC.
3. Create a folder on the source Hyper-V server (e.g. C:\VirtualMachines) and export the virtual machine image of the source virtualized DC to that folder (e.g. C:\VirtualMachines\SourceDCImage).
4. Create a folder on the destination Hyper-V server (e.g. C:\VirtualMachines) and copy the SourceDCImage to that folder.
5. In the Hyper-V Manger of destination Hyper-V server, import the virtual machine you copied to the C:\VirtualMachines\SourceDCImage folder on destination Hyper-V server. Right-click the server name and select Import Virtual Machine.
6. Select the option to Copy the virtual machine (create new unique ID), as shown below. I prefer to select the option to Duplicate all files so the same virtual machine can be imported again. This ensures that I can repeat the process in future and create additional copies if necessary.

   

7. Restart the source virtualized DC.
8. Start the newly imported destination cloned virtualized DC.

This completes the process of cloning a virtualized DC. For more information visit Microsoft’s Web site.

If you try to install Exchange Server 2010 Service Pack 1 (SP1) on a server in the environment where the NetBIOS domain name of a domain controller contains an ampersand (&) character, the server installation will fail and you are likely to see the following error.

An error occurred while parsing EntityName. Line7, position 12.

This issue occurs because the “&” character is a reserved character in XML. Therefore, the character causes the parsing for current logon user to fail. Here’s how you can solve the problem. The solution used to be documented in KB article 2491951 but recently when I tried to find the article on the Internet I was unsuccessful. Luckily, I have documented the solution for you in the following steps.

1. Copy all the installation files from the CD to a hard disk, and then open the ManageScheduledTask.ps1 file in the scripts folder.
2. Locate the following lines.
   function Get-CurrentUserName
   {
   [System.Security.Principal.WindowsIdentity]$id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
   $id.Name
   }
3. Change the lines as below.
   function Get-CurrentUserName
   {
   [System.Security.Principal.WindowsIdentity]$id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
   [System.String]$fixedName = $id.Name.Replace(‘&’,'`&amp;’)
   return $fixedName
   }
4. Save the file, and then try to install Exchange Server 2010 SP1 from the hard disk.
5. Install Update Rollup 4 for Exchange Server 2010 Service Pack 1.