Everyone that is using a domain based DFS namespace with more than one target most certainly is using FRS to replicate the data between the replica's. R2 provides a new state-based replication mechanism called 'DFS Replication'. REMARK: from this point the DFS folder is available through the DFS namespace and replication is working. However when looking from the DFS Namespaces node by selecting the DFS folder and then the Replication TAB it will show: "Replication status: not configured". And when looking from the DFS Replication node by selecting the replication group and then the replicated folders TAB it will show: "Publication status: not published". The main reason for this is because an attribute is not populated (we will take care of that later!)
A summarization of its very cool features and characteristics:
(1) Configure each existing DFS folder using FRS replication within A SEPARATE DFS-R replication group with one replicated folder
(2) Configure each existing DFS folder using FRS replication within A SEPARATE OR EXISTING DFS-R replication group. This way one replication group can contain one or more DFS folders as replicated folders that share the same replication topology, replication schema and bandwidth usage.
Before starting with the migration from FRS to DFS-R, I do recommend that one first reads the following document as it contains information on how to setup/design DFS Namespaces and DFS Replication:
REMARK: sharing and publishing the folder into the desired DFS namespace will not work because the DFS folder already exists in the DFS namespace
If you use this information, please be so kind to post any comments you have!
And of course: TRY IT FIRST IN A TEST ENVIRONMENT AND SEE IF THE RESULTS ARE SATISFYING!!!
Showing posts with label Windows Server. Show all posts
Showing posts with label Windows Server. Show all posts
Migrating from FRS to DFS-R
With the legacy 'Distributed File System' a namespace was created with underlying DFS folders. When one of the DFS folders had two or more DFS folder targets, replication could be setup using FRS and by choosing one of the DFS folder targets as primary master replica to start replication from that same replica to the other replicas.
With the new 'DFS Namespaces' a namespace was created with underlying DFS folders. When one of the DFS folders had two or more DFS folder targets, replication could be setup using DFS-R by creating a NEW replication group that contain the DFS folder targets a replication group members and contain the DFS folder as a replicated folder. Unfortunately, when working from the 'DFS Namespaces' node it is not possible to add the DFS folder as a replicated folder to an existing replication group. To be able to do that you first select an existing replication group, add a new replicated folder and select the replication group members that host that replicated folder. Last step is to SHARE and PUBLISH the replicated folder as a DFS folder in a DFS namespace. For the last part to succeed that DFS folder must not yet exist in the desired DFS namespace (very important!). Each replication group can contain one or more replicated folders.
So what is different in the concept between FRS and DFS-R? The main difference here is that each DFS folder using FRS for replication can be compared to ONE replication group only having ONE replicated folder. And as you just have read DFS-R can have replication groups with MULTIPLE replicated folders.
When migrating from FRS to DFS-R you have to possibilties:
The high-level steps to migrate from FRS to DFS-R are:
To create and configure DFS replication groups and to assign and configure replicated folder the 'DFS Management' MMC can be used or the command utility 'dfsradmin.exe' can be used. The latter, of course. can be usefull in performing repeated tasks!
Well.... this is it! ENJOY!
Tracking LDAP Searches with Windows Server 2008 Reliability and Performance Monitor
Windows Server 2008 ships with the Reliability and Performance Monitor (RPM) snap-in. On DCs, RPM incorporates an Active Directory Diagnostics feature that includes the abilility to track LDAP searches against a DC. The amount of information captured can be very useful when troubleshooting LDAP issues.
This article provides a step by step guide on how to use RPM to track LDAP searches.
Tracking LDAP activity on a specific DC is not trivial to achieve with the native toolset. A few years back, I posted an article on ActiveDir.org that showed how to log all LDAP activity by enabling diagnostic logging and tweaking the inefficient and expensive LDAP search thresholds. The article is available here:
The problem with the approach shown in that article is its inability to help with LDAP failures. For example, the information logged will not show LDAP failures due to protocol errors.
When troubleshooting an application that is exhibiting LDAP problems another alternative is to trace the activity at the network level using tools such as Ethereal or Microsoft's NetMon. The information available with tracing is certainly detailed, but troubleshooting problems can be a little like finding a needle in a haystack, especially if the data is encrypted over an SSL connection. You could also look at command line tools such as LogMan and TraceRpt.
Windows Server 2008 ships with the Reliability and Performance Monitor, a tool that allows to you easily troubleshoot problematic LDAP searches. This article provides a step-by-step guide on how to leverage this useful feature of the latest version of Windows Server.
Tracking LDAP searches with RPM
Log onto the DC and select Start -> Run and type perfmon in the box.
When the snap-in opens, expand Data Collector Sets and System and then click on Active Directory Diagnostics. Click the green start button on the action bar. This initiates the collection of AD related information on your DC.
While RPM is collecting data, run your LDAP search against the DC. When you have finished click the stop button on the action menu, as shown below.
To view the report of the information you have collected, click the green report button on the action menu.
The report will take some time to generate. On my DC running on a fairly sluggish virtual machine it can take up to a minute. During the wait, you will be presented with the screen shown below.
Once the report has generated, you can dive straight into the Search option by moving down to the Active Directory section and clicking the summary button (highlighted in red below). From the summary window, select Unique Searches.
At this point you should be able to identify the search that you are interested in. Note that the report only shows the “highest 25” searches. Quite what criteria RPM uses to identify the highest 25 searches is not clear, but I assume that it is CPU usage. The report shows a fair amount of detail about each search, as explained in the table below.
Label | Example | Explanation |
Client | 192.168.83.1814 | Client IP address and source port number |
Instance | NTDS | Always NTDS for AD DS. May be different for AD LDS. |
Scope | Deep | LDAP search scope. Will be one of base, one-level or deep (subtree). |
Object Name | DC=ad,DC=fisheagle,DC=net | Search base, i.e. the Distinguished Name of the object from which the base will start. |
Filter Name | (&(objectClass=user)(sn=n*)) | The LDAP search filter used. |
Index | idx_sn:6:N; | The internal index used for the search. In this example, the index for surname (sn) was used. |
Status | 0 | The result of the search. A value indicates that the search completed successfully. |
Visited | 6 | The number of objects visited by the search. |
Found | 6 | The number of objects found by the search. |
Requests/Sec | 0 | The number of requests made per second. Typically, this is 0. |
Response Time (ms) | 1 | The number of milliseconds the search took to complete. |
CPU % | 0 | The percentage of CPU the search used. |
While the HTML report is useful, you also have the option of looking at the raw XML data. To do this, highlight the report in the left hand pane and select View -> Folder.
The right hand pane will then display the files all the files used for the data capture and for the report. The file named report.xml contains the XML content.
Within the XML report file, a search will appear as shown below.
192.168.83.110:1814
NTDS
deep
DC=ad,DC=fisheagle,DC=net
( & (objectClass=user) (sn=n*) )
idx_sn:6:N;
0
6
6
0.020444
1.395700
0.000000
While the example shown above is simple, hopefully you can see the potential for the tool when troubleshooting LDAP issues on a DC. If nothing else, it provides a useful addition to your armoury of troubleshooting and diagnostic tools.
Some background on Reliability and Performance Monitor (RPM)
RPM is a Microsoft Management Console (MMC) snap-in that can be launched either from within Administrative Tools for by running perfmon.msc directly from Start Run. The tool brings together the features of previous stand-alone tools including Performance Logs and Alerts, Server Performance Advisor, and System Monitor. It also provides new functionality in the form of Reliability Monitor, a feature that tracks changes to the system and provides you with a graphical view and a report showing system stability over time.
The SPA heritage
The ability to report the details of LDAP searches made against a DC was provided in a downloadable add-on for Windows Server 2003 called the Server Performance Advisor (SPA). The latest version (2.0) is still available for download at the following URL.
I blogged about how to troubleshot LDAP issues with SPA a few years back. You can find the blog entry here:
Much of the functionality in the Windows Server 2008 Reliability and Performance Monitor appears to be derived from the SPA, although there are some fundamental differences in the look and feel and with some of the features.
Mapping of MMC display names to snap-in file names (*.msc)
This mapping can be useful for those who like to launch snap-ins from the command line or from Start -> Run.
The mapping is shown below. A Word document with the same content is attached if you prefer to download the information.
Display Name File Name
Active Directory Management admgmt.msc
ADSI Edit adsiedit.msc
Application Server appsrv.msc
Authorization Manager azman.msc
Certificates certmgr.msc
Certificate Authority certsrv.msc
Certificate Templates certtmpl.msc
Indexing Service ciadv.msc
Component Services comexp.msc
Computer Management compmgmt.msc
Default Domain Controller Security Settings dcpol.msc
Device Manager devmgmt.msc
Disk defragmenter dfrg.msc
Distributed File System dfsgui.msc
DHCP dhcpmgmt.msc
Disk Management diskmgmt.msc
DNS dnsmgmt.msc
Active Directory Domains and Trusts domain.msc
Default Domain Security Settings dompol.msc
Active Directory Users and Computers dsa.msc
Active Directory Sites and Services dssite.msc
Event Viewer eventvwr.msc
Exchange System Manager Exchange System Manager.msc
File Server Management filesvr.msc
Shared Folders fsmgmt.msc
Microsoft Fax Service Manager fxsadmin.msc
Group Policy gpedit.msc
Group Policy Management gpmc.msc
Internet Authentication Service ias.msc
Internet Information Services iis.msc
IP Address Management ipaddrmgmt.msc
Local Users and Groups lusrmgr.msc
.NET Configuration 1.1 mscorcfg.msc
Removable Storage ntmsmgr.msc
Removable Storage Operator Requests ntmsoprq.msc
Performance perfmon.msc
Enterprise PKI pkiview.msc
Public Key Management pkmgmt.msc
Routing and Remote Access rrasmgmt.msc
Remote Storage rsadmin.msc
Resultant Set of Policy rsop.msc
Active Directory Schema schmmgmt.msc
Local Security Settings secpol.msc
Services services.msc
Sidwalk sidwalk.msc
Telephony tapimgmt.msc
Terminal Services Configuration/Connections tscc.msc
Remote Desktops tsmmc.msc
UDDI Services Console uddi.msc
Active Directory Users and Computers (Exchange version) users and computers.msc
WINS winsmgmt.msc
Windows Management Infrastructure (WMI) wmimgmt.msc
Multiple Domain Forests: Still a Valid Design Model?
On the ActiveDir.org list there has been some good discussion about whether the multi-domain forest is still considered a valid design option. This article attempts to crystallise the discussion for use as a reference for those involved with the design or review of forest models.
The general consensus is that single domain forests are now the preferred design option for all but the most marginal cases. Note that this does not preclude the use of multiple forests within a single organisation. For example, the use of the Exchange Resource forest in environments that have a distributed NOS architecture but a centralised messaging architecture is common in larger organisations.
Background
When Active Directory was first launched along with Windows 2000, a number of well-known global IT consultancies adopted multi-domain models. In fact a single domain forest in the early days of AD was rare outside the lab environment. This may have partly been a hangover from the days of NT 4.0 when domains proliferated everywhere. Since then there have been a lot of changes to AD as well as a change in thinking about domains as security boundaries.
When Windows 2000 first arrived a popular forest model was the 1+1 domain approach. There would be the so-called dedicated or “empty forest root” domain, hosting a few protected groups and accounts, and a second domain (sometimes in a separate tree) containing all the users, groups, computers, etc. The rationale behind this model was to protect the keys to the kingdom (i.e. the Enterprise Admins, Schema Admins, root Domain Admins groups, as well as other accounts and groups considered sensitive). At that time the domain was thought to be a security boundary as well as an administrative and replication boundary.
A little while after Windows 2000 had been in place the realisation dawned that the domain was not a true security boundary. It is, for example, possible for someone with Domain Admins rights in a child domain to gain control of the forest. I won’t provide details of the mechanism here as a number of AD implementations are still susceptible to it.
A number of other reasons have been put forward for a multiple domain forest model. Are any of these still valid? Let’s take a closer look at the more popular reasons.
The multi-domain model allows for separate password policies to be defined
In Windows 2000 and 2003 Active Directory password and account lockout policies were defined at the domain level. These could not be overridden by policies defined at a more granular level (e.g. user, group, or OU). Windows Server 2008 introduces Fine-Grain Password Policies (FGPPs) to allow a granular definition of password policies. Once defined, a policy that takes precedence over the default domain password policy can be linked to users (not considered best practice) or groups.
The separation of password policies was often cited as another justification for the 1+1 model, with more restrictive policies being defined in the forest root to “protect” certain accounts. Given that Fine-Grained Password Policies are now available, there is no longer a need to have a separate domain simply to provide stronger policies for certain accounts.
Smaller replication scope for DNS zones.
There is an argument that specific DNS zones can be integrated in the root domain, and use replication in the domain scope only, thus reducing the replication overhead.
Since the introduction of application partitions in Windows Server 2003, Active Directory-integrated DNS zone data can be stored in an application directory partition. This allows administrators to manage replication traffic by controlling which DCs hold a copy of the DNS zone data.
An empty forest root offers naming flexibility
The empty forest root is often given a generic name (e.g. root.local). In a world where mergers, acquisitions and divestitures are frequent, the idea is that the generically named forest root allows for child domain changes to occur without having to change the forest name.
If your company changes name, does it really matter if your domain name stays the same? You can hide the name in most cases through the use of UPN logins where the UPN suffix can be different to the domain name. Similarly, company SMTP addresses don’t have to be tied to the domain name.
Despite requiring an unreasonable degree of effort and the fact that it cannot be done with Exchange 2007 in the forest, domain renames are possible since Windows 2003. The fact that you now have ability to rename a domain makes the argument for a generically named forest root less compelling.
While the naming flexibility argument still has some validity, bear in mind that the domain is not a security boundary. In other words are all the domains happy to trust the Domain Admins in other domains? Are they happy to trust the physical security of the DCs in other domains? If not, then separate forests are probably required anyway.
Also consider that despite providing some naming flexibility, the empty forest root approach can actually be more inflexible model than a single domain forest. In a divestiture scenario, for example, it is far more difficult to take out a child domain from an existing forest than it is to simply hand over a single domain forest.
Multiple Domains reduce replication traffic
A common approach for organisations distributed across a wide range of physical sites is to create domains based on region in order to reduce replication traffic between DCs. For example a global company with a forest named acme.com might have child domains named americas.acme.com, emea.acme.com and apac.acme.com. Domain naming contexts are only replicated to DCs within the same domain, which means the regional approach adopted by acme.com could significantly reduce overall replication traffic.
At first glance this appears to be a very sensible approach, especially in environments that have limited bandwidth between sites. This design is tempered with the downside that each additional domain in the forest increases the complexity of the infrastructure as well as administrative overhead and, likely, hardware requirements.
Also consider that Windows Server 2003 introduces the Linked Value Replication (LVR) feature, which improves the replication behaviour for linked attributes. A good example is the member attribute of a group object. Without LVR, the entire attribute value is replicated when a change is made, which can be quite large if you consider a group with 5000 members. With LVR only the item-level change is replicated, not the whole attribute value. The overall effect of LVR can be significant in reducing the replication overhead been DCs.
Windows Server 2003 brought in an improved compression algorithm, which is much faster than the Windows 2000 algorithm and reduces the performance overhead on DCs. Having said that, the compression ratio is not quite as good with the Windows Server 2003 version, so Microsoft recommends reverting back to 2000 behaviour for slow bandwidth links (e.g. 64Kbps or lower) by making a registry change. The point is that, for all but the worst inter-site links, overall replication performance has been improved since Windows 2000.
Conclusion
The majority of arguments for multiple domain forest models (including the 1+1 empty forest root model) can be called into question. Realisation that the domain is not a security boundary has led to a re-think about the viability of multiple domain forests. Technical improvements such as domain renaming and LVR in Windows Server 2003 and the introduction of FGPP in Windows Sever 2008 have further eroded arguments supporting a multiple domain approach. Multiple domain models also often incur higher capital and operating costs whilst delivering, at best, marginal benefit.
The single domain forest model should be considered the best practice standard, with a multi-domain model being reserved for marginal cases where political or environmental factors (such as extremely low bandwidth) come into play.
Considerations when using a domain-based service account with AD LDS
When creating an AD LDS instance you are prompted to specify an account to use as the service account. At this point you can specify either the Network Service account or another account. Unless you have a particular need, you should choose the built-in Network Service account. If you opt for a domain-based service account you have to jump through a whole lot of hoops to get things working. Also, you typically end up giving your domain-based service account more permissions than are strictly necessary (as described later in this article). The Network Service account on the other hand provides an easy set up option and is a good choice from a security perspective given that the account has limited access to the local computer.
So why bother to use a domain-based service account at all? Well, if you have a number of services on your server all running under the context of the Network Service account there is potential for security compromise. In this scenario you may want to consider isolating the services from each other using dedicated service accounts.
What follows is a discussion of the steps required to configure AD LDS to use a domain-based service account.
1. Create a user account in AD.
The account doesn't require any specific group memberships. As a service account, you may want to give some thought to the "Password Never Expires" setting, as well as password complexity.
2. Permission to create serviceConnectionPoint objects.
The account you have created requires the ability to create Service Connection Point objects in AD. These objects are typically created automatically as child objects of the AD LDS computer object when the service is started.
The simplest method is to set the permission using DSACLS. You could alternatively use the security editor from within dsa.msc or adsiedit.msc, but you would first need to edit the %systemroot%\system32\dssec.dat file to expose the serviceConnectionPoint object. Here's the syntax using DSACLS:
C:\>dsacls /G :CC;"serviceConnectionPoint"
e.g.
C:\>dsacls "CN=ADLDS1,OU=Servers,DC=Widget,DC=com" /G MyDom\ADLDS_SVC:CC;"serviceConnectionPoint"
The setting should appear similar to that shown in the screenshot below.
3. Permission to create servicePrincipalName objects.
Your service account also needs permissions to create Service Principal Name (SPN). The SPNs are generated automatically as attributes of the service account itself in AD when the service is first started. Note that this is different from the behaviour when running the service under the Network Service account. When using Network Service, the SPNs are created as attributes of the AD LDS server's computer object.
To set the permissions, assign the SELF account Read/Write servicePrincipalName. The permissions are applied onto This object only on the service account object. Here's an example using DSACLS.
C:\>dsacls /G SELF:RPWP;"servicePrincipalName"
e.g.
C:\>dsacls "CN=ADLDS_SVC,OU=Service Account,DC=Widget,DC=com" /G SELF:RPWP;"servicePrincipalName"
The screenshot below shows how the permissions should appear.
4. Grant "Log on as a service" user rights
The service account requires Log on as service user rights on the server running the AD LDS instance. You don't normally have to assign this right in advance because you will be prompted when creating the instance using the setup wizard.
If you have to set this right manually, use the Group Policy Editor to edit the local policy, or alternatively use the GPMC to edit an appropriate domain policy. The location of the setting is:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
The screenshot below shows the setting.
5. Membership of the local Administrators group.
At the time of writing, the AD LDS product documentation indicates that the service account is not required to be a member of the local Administrators group on server running the AD LDS instance. However, my experience is that without this, the following error is generated in the event log corresponding to the instance each time the service is re-started.
Log Name: ADAM (instance1)
Source: ADAM [instance1] General
Date: 6/04/2009 11:22:08 a.m.
Event ID: 1168
Task Category: Internal Processing
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: ADLDS1.widget.com
Description:
Internal error: An Active Directory Lightweight Directory Services error has occurred.
Additional Data
Error value (decimal):
-1073741790
Error value (hex):
c0000022
Internal ID:
3000715
Source: ADAM [instance1] General
Date: 6/04/2009 11:22:08 a.m.
Event ID: 1168
Task Category: Internal Processing
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: ADLDS1.widget.com
Description:
Internal error: An Active Directory Lightweight Directory Services error has occurred.
Additional Data
Error value (decimal):
-1073741790
Error value (hex):
c0000022
Internal ID:
3000715
The fact that the service account requires membership of the local Administrators group makes the choice to use Network Service even more compelling. The Network Service account has a lower level of privilege on the local machine than that of members of the Administrators group. This implies the potential for compromise is lower when using Network Service.
Conclusion
As you can see, using domain-based service accounts for your AD LDS instances requires a fair amount of extra work during setup. I recommend that you use Network Service unless your circumstances require you to use a domain account.
Subscribe to:
Posts (Atom)
