a blog about nothing

If you use DirectAccess (DA), should you use a certificate on the IP-HTTPS listener from your internal CA or from a third party CA?

If you use a certificate from your internal CA, you’ll have to publish the CRL so it can be reached from the outside. If you don’t do it, external DA clients will remove the CRL from the cache after 24 hours and they will not be able to check if the certificate has been revoked or similar. DA will not work for them until they put their laptop in the internal network, and are able to reach the CRL.

The default time for the cache is 24 hours.

So I would not bother publishing the CRL, but instead use a third party certificate on the IP-HPPS listener.

If you use or consider using DA without UAG, Win8 has a lot of improvements regarding DA (features you only found in UAG).

For a complete list check out http://technet.microsoft.com/nb-no/library/hh831416.aspx

When you use DirectAccess (DA) you have to unblock ISATAP on your DNS servers, so when clients do a DNS lookup for ISATAP they will get an answer.

If you add a new domain controller with the DNS role, you must remember to remove ISATAP from the block list. You removed it on your DNS servers when you configured DA long time ago, but will you or your successor remember to remove the blocking if you add a new DC/DNS?

I didn’t until I saw a 7600 event id on the new DC/DNS…

Too see the current settings:

dnscmd /info /globalqueryblocklist

To remove ISATAP manually from the block list:

dnscmd /config /globalqueryblocklist wpad

To avoid this from happening in the future, I configured a Group Policy (GPO) to do the job. I reckon a GPO is more reliable than a Teflon brain.

Open the Group Policy Management consol.

Create the WMI:

First you need to create a WMI filter so the GPO only apply to servers with the DNS server role. Give it a meaningful name.

Query:  SELECT id FROM Win32_ServerFeature WHERE id = "13"

(ID 13 = DNS Server)

Create the GPO/GPP:

Group Policy Objects -> New

Give it a name. I called it “GPP_Unblock_ISATAP”.

Computer Configuration – Preferences – Windows Settings – Registry

Choose New – Registry Item

Action: Update

Path: HKLM\System\CurrentControlSet\Services\DNS\Parameters

Name: GlobalQueryBlockList

Value to remove: isatap

Link the GPO to the WMI filter you created:

Link the GPO to the OU where your DNS servers reside. I linked it to the Domain Controllers OU since we don’t have any standalone DNS servers. The WMI filter will anyway only apply to DNS servers, so you can link it higher up.

You’ll have to restart the DNS server service, or reboot the server before the setting is applied to the DNS server. Check the status “dnscmd /info /globalqueryblocklist”. If ISATAP is not present you are good to go.

Notice this only apply to Win2008 and newer, since legacy OS don’t have the Win32_ServerFeature class.

If you have Win2003 DNS servers, you’ll see that the WMI filter return “false” and the GPO will not apply:

On Win2008 and newer:

 

 

For proper Kerberos authentication to take place, the Service Principal Names (SPNs) have to be registered correctly on the correct account.

SPNs are AD attributes that uniquely identifies an instance of a service for a given target host.

If you have a SQL server where the SQL service run under the Network Service or Local System account, the SPN for SQL should be registered on the machine account. If you have set the service to run under a service account (a domain user account), the SPN should be registered on the domain user.

SPNs registered on a machine account will be registered automatically, but if you use a user account you’ll have to register the SPN manually. You can use the setspn.exe tool, or use adsiedit.msc.

You can only register the unique SPN on one account. If you have duplicate SPNs in the forest, Kerberos authentication will fail.

If you have an IIS server (version 6 or prior) the Service class (http) should be registered on the application pool Identity the site is using. This is not the case if you have IIS 7/7.5. By default IIS 7 has enabled “Kernel-Mode authentication”.  The Kerberos Service ticket is then encrypted with the Machine account password no matter what account is set to run the application pool.

 

 

Consider the following environment:

3 x Win2008R2 SP1 RDS (terminal servers with load balancing)
1 x Win2008R2 SP1 Microsoft Dynamics CRM 2011 (Rollup pack 2 at the moment)
CRM for Outlook installed on the RDS servers.

Since you don’t want users to save documents, pictures, etc. on the RDS servers, and you want the users environment to be the same no matter what RDS server they happen to be routed to, you configure Folder Redirection and Roaming Profiles.

Doing this will leave your MS CRM installation in an unsupported state as MS CRM 4 and CRM 2011 don’t support Folder Redirection.

Problems I experienced:

If you open up a window from CRM and then you close it, you’ll get: “An error occurred. Send Report to Microsoft?”

If you open CRM for Outlook as a normal user, and you try to track an email, you’ll get and error stating that it didn’t work. If you look in the Event log on the RDS server you’ll see:

EventID 5972 Source MSCRMAddin

I opened a support case with Microsoft, and got in contact with the MS CRM team. They told me that Folder Redirection (FR) is unsupported in MS CRM, so I had to remove FR if they should be able to investigate any further.

That would be a huge drawback, since we uses load balancing between the RDS’s, and the users would be saving documents directly on the RDS servers. Ouch!

Solution: Remove Folder Redirection completly

Solution (unsupported):

There are two files (caches) that have to be local on the RDS for CRM to work. “EmailCache.sdf” and “OutlookSyncCache.sdf”.

They are located in the “%userprofile%\AppData\Roaming\Microsoft\MSCRM” folder. If you redirect “Appdata(Roaming)” those two files will be on a file share. That will cause problems for the CRM client and present you some weird errors.

So if you have to use FR, you can’t redirect “AppData”. That folder has to be local. The rest of the folders didn’t seem to cause any problems redirecting.

There are no official KB’s stating that Folder Redirection is unsupported in CRM 4 and CRM 2011, but it is. The CRM support team told me the product team was working on it, and there might come a resolution in the upcoming versions / rollups.

COYS!

Without Folder Redirection, users might/will save data on their local profile on their computer. If they accidentally delete such a file, you don’t have a backup of it (unless you take backups of workstations which I doubt…).

Configuring Folder Redirection is fairly easy, but you should get it configured correctly.

In this step-by-step I will just use a domain controller (DC) to store the user folders. I always strive to keep DCs dedicated and don’t mix other roles to them. If you don’t have the HW or budget I guess you don’t have a choice.

Open up the “Share and Storage Manager” (that came along with Win2008, which in fact is a great tool).

In the Action frame, choose “Provision Share”:

Click “Browse” and “Make new folder”. Give it a meaningful name like “FolderRedir” or similar:

   

  Edit the NTFS permissions:

Remove the inheritance so it don’t get permissions from its parent folder:

Permissions:

Administrators: Full Control, “This folder, subfolders and files”
System: Full Control, “This folder, subfolders and files”
Users (or a group containing the domain users): READ & Execute + “Create folders / Append data”, “This folder only”
Creator Owner: Full Control, “Subfolders and files only“

Give it a share name and make it administrative (add a $ at the end of the share name):

Enable “Access-based enumeration” (optional). This feature will only list folders the user has access to when browsing:

Set the share permissions:

Domain admins: Full Control
Users (or a group containing the domain users): Full Control

If you use DFS, you should consider placing the folder redirection on the DFS for redundancy. If you don’t have it, just click Next:

Hit Next and Create the good stuff.

With the share and NTFS permissions in place, you have to create a Group Policy Object (GPO):

Open the Group Policy Management Consol:

Create a new GPO, and give it an informative name. I.e. “GPO_FolderRedir”.

Navigate to “User Configuration – Windows Settings – Folder Redirection”. You now have to decide what you want to redirect. You can redirect all, or just a few. “Documents”, “Desktop”  and “Favorites” are handsome to pick if you don’t pick all.

If all your users should be on the same share, you should use the “Basic” setting. If you have different shares for different domain groups you can use the “Advanced” setting.

Set “Root Path” = the share path you created earlier.

On the Settings tab, untick the “Grant the users exclusive rights to Documents” if you want domain admins to have access to the redirected folders. If you don’t untick it now and the folders are created, unticking it at a later time will not give domain admins access to the already created folders. You have to take ownership on the folder to gain access. If a user logs on the redirection will not work as the user has to be the owner.

Now you can link the GPO to an OU (not a Container like “Users”) where the users resides.
When the users logs on, the folders are created automatically and the permissions are set correctly. If the user saves i.e. a Word document to My Documents, it’s saved on the file server.

If you have terminal server users, folder redirection in conjunction with Roaming Profiles is a m.u.s.t!

COYS! 
(even though Manchester City bought a Champions League place)

When you have renamed a domain there will be some registry keys left with the old domain name under HKLM\System\CCS\Services\NTDS\Parameters

Name: “Configuration NC”
Type: reg_sz
Value: CN=Configuration,DC=oldname,DC=com

Name: “Machine DN Name”
Type: reg_sz
Value: CN=NTDS Settings,……,CN=Configuration,DC=oldname,DC=com

Name: “Src Srv objectGuid”
Type: reg_binary
Value: <some_DC>.oldname.com

Those keys where created by LSASS.exe when the DC was created with DCPROMO. Rendom.exe will not modify them. They are not vital and are not in use. You can update those keys for consistency if you like.

Credit to Ned Pyle at AskDS for the information.

Applies to Server 2003/2008. Not for Windows 2000.

Time is crucial in an Active Directory domain. If there are i.e. more than 5 minutes offset between a DC and a client computer, the Kerberos protocol used for authentication will fail.

You may also see problems with AD replication if two DCs are out of time sync, since attributes that are changed are time stamped when the change occurred. The time stamp is one of three functions to prevent replication/attribute conflicts.

When a user logs on to his/her workstation and authenticates, the computer will synchronize its time with the authenticating DC.

This DC, if it’s not the PDC role holder, synchronizes its time with the domain’s PDCe role holder.

The PDCe holder should synchronize its time with a reliable time source. You could find a NTP server close to you HER.
If the DC holding the PDC dies, the role is transferred or siezed you have to configure the time source on the new PDCe.
Configuring the external time source can be a mess, and maintaining it might be even more messy

The MS DS team made a blog entry about this some time ago and I must say it’s a really elegant approach!!

In short terms they create a GPO, sets an external time source, configures a WMI filter so the GPO only applies to the domains PDCe role holder, and link the GPO to the Domain Controller container.

Open the GPMC and create a new WMI filter:

 

 

 

 

 

 

 

 

 

Query: Select * from Win32_ComputerSystem where DomainRole = 5

Create a new GPO and set the external time source:

Computer Configuration/Administrative Templates/System/Windows Time Service/Time Providers/Configure Windows NTP Client

You set the NtpServer you prefer and change the type to NTP.

 

 

 

 

 

 

 

 

 

Activate the WMI filter to this GPO:

 

 

 

 

 

 

 

 

 

 

and link the GPO to the Domain Controllers container:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

To see how the DCs is synchronizing their time, run: w32tm / monitor

 

 

 

Here dc01test.spurs.local (the PDCe holder) uses its HW clock while dc4test.spurs.local is synchronizing with dc01test.

Restart the time service (net stop w32time && net start w32time) and force a Group Policy update (gpupdate /force or wait 5 minutes)

Now the newly created GPO is applied and now dc01test is synchronizing with the external time source.

 

 

 

 

You can also see this in the System Event log:

 

 

 

 

 

 

 

 

So what happens if I transfer the PDCe role from dc01test to dc4test?

I wait for 5 minutes (and run w32tm /monitor just to check):

 

 

 

 

As you can see dc4test is now synchronizing with the external time source, while dc01test is synchronizing with dc4test.

You don’t have to think of configure the time source if your PDCe is transferred.
You even don’t have to clean the old PDCe holder as the registry don’t gets tattooed by this!!!
If you configure the time with a GPO, the registry settings will be located here:

HKLM/Software/Policies/Microsoft/Windows/W32time

If you don’t use a GPO, the settings will be set here:

HKLM/System/CurrentControlSet/Services/W32time

The first one takes precedence over the second one.

References:

http://www.pool.ntp.org/en/

http://support.microsoft.com/kb/816042

http://blogs.technet.com/b/askds/archive/2008/11/13/configuring-an-authoritative-time-server-with-group-policy-using-wmi-filtering.aspx

Domain renaming is not a daily task but a task you do if the management forces you to do it! (ie. because of a company restructure, take over etc )

There are many resources on the Internet sharing a “walk through” about this job, but I made my own documentation some years ago when I was told to rename the domain. So I just go with the flow and publish it.

To do this task your domain/forest functional level has to be at least 2003 and all DC’s need at least SP1.

Exchange 2003 SP2. This is the only version that supports a domain rename. Exchange 5.5, 2000 and 2007 is not supported and Exchange can’t be installed on a DC.

Before you proceed you do have to read the official documentation and requirements from Microsoft:  http://technet.microsoft.com/nb-no/windowsserver/bb405948(en-us).aspx

– Download the domain rename tools

– Understanding How Domain Rename Works

– Step-by-Step Guide to Implementing Domain Rename

The environment consisted of:

One forest (2003 Functional level) with three domains (2003 FL, transitive trust and a parent-child trust), six DC’s (Win2003 SP1) and four Exchange servers (Win2003 SP1 with Exchange SP1).

The objective was to rename one of the three domains. (The domain without a child).

Before we started banging on the production environment, we made a test environment to test the rename and its impact on all third-part applications like Citrix, MSSQL based applications, HP Data Protector. After a month of testing and three successful renaming, we moved over to the production environment.

Preparing:

To increase your chance of a successful renaming your domain have to be in a good shape.

· Your event logs should be clean on all DC’s and Exchange servers
· “dcdiag /v /e /c” should be clean
· “netdiag /debug /v” should be clean

You need to have a domain member to act as the Control station (CS). Should be at least a Win2003 SP1 server. Log on to the control station with an enterprise admin (I guess you don’t bother the “run as” in this situation) and download the domain rename tools to this server (domainrename.exe and xdr-fixup.exe).

Install by running the domainrename.exe. It will install rendom.exe and gpfixup.exe to “C:\Program files\Microsoft Domain Rename Tools”

Copy both these files to “C:\Rename”

Now it’s time to take some System State backups of your domain controllers and keep them in a safe place.

In this documentation I will use theses domain names:

Old domain name: tottenham.int
New domain name: spurs.local

Create a new DNS zone:

· Open the DNS management consoll (dnsmgmt.msc)
· Right click “Forward Lookup Zones” > “Add new forward lookup zone”
· Call it “spurs.local” (without quotes)
· If you have a trusting domain, create the same zone as a secondary zone in the trusting domain

DNS suffix:

When you rename the domain the DNS suffix in the domain will change. Two conditions must be checked:

· The computers DNS suffix should be configured to change when the domain membership changes (default)
· No Group Policy must configured to set the primary DNS suffix to computers.

Do the renaming procedure:

Open cmd and change the directory to “C:\Rename”.

1. rendom /list

· This will create a list of the directory partitions in the forest
· Copy the “domainlist.xml” file to “domainlist-save.xml”
· Open “domainlist.xml” in Notepad and change it to the new forest description

2. rendom /showforest

· Verify that it reflect the new domain name

3. rendom /upload

· Generates the domain rename instructions
· Pushes the rename instruction to all DC’s
· Force a replication. “repadmin /syncall /APed”

4. rendom /prepare

· Verify that all DC’s are ready
· You should get an answer from all DC’s and they should NOT return an error. If they do, open “dclist.xml” (that was created in step 3). The DC’s that have reported errors will not be tagged with <state>prepared</state>. You have to troubleshoot any errors. DO NOT set the state to “prepared” manually in this file for any DCs!

You should fix any errors and re-run “rendom /prepare” until all DCs are in the “prepared” state.

5. rendom /execute

· If everything goes as planned you should get an answer from all DCs. The DCs will reboot automatically. When the DCs are back online the domain name is changed, but not the DNS suffix on the DCs itself. This has to be done manually on each DC in the renamed domain:

Add the new DNS suffix:

· netdom computername dc01.tottenham.int /add:dc01.spurs.local

Change the primary DNS suffix:

· netdom computername dc01.tottenham.int /makeprimary dc01.spurs.local

Reboot the server.

Remove the old DNS suffix:

· netdom computername dc01.spurs.local /remove:dc01.tottenham.int

Reboot the CS twice!

5.1. Exchange

(still working from the CS):

Before you proceed to the Exchange specific tasks, you got to be sure you are not going back with a domain restore.

· xdr-fixup /s:domainlist-save.xml /e:domainlist.xml /trace:TRACEFILE /changes:CHANGESCRIPT.ldf

This will create two files. changescript.ldf and restorescript.ldf. You run this command only one time (not one time per Exchange server).

· ldifde -i -f changescript.ldf

(to revert, run “ldifde -i -f restorescript.ldf”)

· Restart all Exchange servers twice

6. rendom /end

· this will unfreeze the forest

Side steps:

Reestablish external trusts and validate:

· “nltest /sc-query:foreign_domain.com” (from a DC in the renamed domain)

· “nltest /sc-query:spurs.local” (from the trusting domain)
Fix DFS topology (if you use DFS)

Fix GPO links:

gpfixup /olddns:tottenham.int /newdns:spurs.local /oldnb:tottenham /newnb:spurs /dc:dc01.spurs.local /user:administrator /pwd:password 2>1 > gpfixup.log

Look for errors in the created log.

Take a new System state of the DC’s.

Restart all other servers twice.

Verify the Exchange rename:

· xdrfixup /verify:restorescript.ldf /changes:verifycorrections.ldf

this should give you:

Verified that the server exch01.tottenham.int was renamed to exch01.spurs.local. Verify pass has completed.(it should list all Exchange servers involved in this output)

Verify/update the Recipient Update Services (RUS) which DC it should use.

If applicable, update the Active Directory Connector (ADC)

Reboot every computer in the domain twice. When it’s done. Do the last step **:

7. rendom /clean

Side steps:

· Authorize the DHCP server
· Delete the old Forward Lookup Zone from DNS
· dcdiag /v /e /c
· netdiag /debug /v
· Check Event logs

** If you have many domain member laptops out of the house during the rename, you can wait with step 7 until they have logged on the domain and rebooted twice. I think I waited a week before I ran step 7.

If you run step 7 and there are members that have not been booted twice you have to rejoin them to the domain. I made a script to keep track of computers that have not been updated with the new domain name.

''''''''''''''''''''''''''''''''''''''' Save me as a vbs file '''''''''''''''''''''''''''''''''''''''

On Error Resume Next

Const ADS_SCOPE_SUBTREE = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)

””” Create a text file with all computers holding the old domain name

Set objResultsFile = objFSO.CreateTextFile(“C:\temp\tottenham.txt”, True)  Set objConnection = CreateObject(“ADODB.Connection”) Set objCommand = CreateObject(“ADODB.Command”) 

objConnection.Provider = “ADsDSOObject” objConnection.Open “Active Directory Provider” 

Set objCommand.ActiveConnection = objConnection objCommand.Properties(“Page Size”) = 1000 objCommand.Properties(“Searchscope”) = ADS_SCOPE_SUBTREE  

””’ Modify the query so that it responds to your domain 

objCommand.CommandText = _ “SELECT dnsHostName, distinguishedName FROM ‘LDAP://dc=spurs,dc=local'” & _ “WHERE objectCategory=’computer’ AND dnsHostName=’*tottenham.int'”

Set objRecordSet = objCommand.Execute

Do Until objRecordSet.EOF 

objResultsFile.Write objRecordSet.Fields(“dnsHostName”).Value & ” –> OU: ” objResultsFile.Write objRecordSet.Fields(“distinguishedName”).Value objResultsFile.Writeline objRecordSet.MoveNext Loop

Wscript.Echo objRecordSet.RecordCount objResultsFile.Close

'''''' EOF ''