Microsoft's official enterprise support blog for AD DS and more
Hi. This is your guest writer Mark Renoden. I’m a Senior Premier Field Engineer based in Sydney, Australia and I’m going to talk to you about the use of Event Forwarding to collect security events. This is particularly useful when:
Historically, you’d use a tool like EventCombMT to skim the security logs across your servers for the events of interest but in the case where security event logs quickly roll over, it might come too late.
I'll take the account lock out example. Before I dive into the details of Event Forwarding, there’s some preparation you need to do first. These steps are different for Windows Server 2003, and Windows Server 2008/2008 R2.
Preparing Windows Server 2003 SP2
I’ll show you how to prepare your Windows Server 2003 machines so you’re able to collect security events from them.
1. Make sure you have the Windows Firewall/Internet Connection Sharing (ICS) service started and configured to start automatically.
This doesn’t mean you need the firewall configured – only that you have the service running which is required for the Windows Event Collector service. For example, your Windows Firewall/Internet Connection Sharing (ICS) service can be running but your firewall can be off.
2. Download and install the Windows Remote Management package from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21900 3. Grant the Network Service account READ access to the security event log by appending (A;;0x1;;;NS) to the following registry value:
2. Download and install the Windows Remote Management package from
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21900
3. Grant the Network Service account READ access to the security event log by appending (A;;0x1;;;NS) to the following registry value:
Key: HKLM/SYSTEM/CurrentControlSet/Services/EventLog/Security
Value: CustomSD
For example, the default security descriptor with READ for the Network Service appended is: O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;NS)
For example, the default security descriptor with READ for the Network Service appended is:
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;NS)
The CustomSD registry value accepts a security descriptor using the Security Descriptor Definition Language (SDDL). You can read more about SDDL here: http://msdn.microsoft.com/en-us/library/aa379567(v=VS.85).aspx You can deploy this step on a larger scale using Group Policy as detailed in: How to set event log security locally or by using Group Policy in Windows Server 2003 http://support.microsoft.com/kb/323076/en-au For Windows Server 2008 or later, you can also use Group Policy Preferences to deploy registry settings Information about new Group Policy preferences in Windows Server 2008 http://support.microsoft.com/kb/943729
The CustomSD registry value accepts a security descriptor using the Security Descriptor Definition Language (SDDL). You can read more about SDDL here:
http://msdn.microsoft.com/en-us/library/aa379567(v=VS.85).aspx
You can deploy this step on a larger scale using Group Policy as detailed in:
How to set event log security locally or by using Group Policy in Windows Server 2003 http://support.microsoft.com/kb/323076/en-au
For Windows Server 2008 or later, you can also use Group Policy Preferences to deploy registry settings
Information about new Group Policy preferences in Windows Server 2008 http://support.microsoft.com/kb/943729
Preparing Windows Server 2008 and Windows Server 2008 R2
Just like Windows Server 2003, you have to prepare your Windows Server 2008/2008 R2 machines for collection of security events. To do this, simply add the Network Service account to the Built-in Event Log Readers group.
If instead, you’d like to be more specific and restrict Network Service account READ access to just the security event log, you can modify the security event log security descriptor as follows.
1. Open up a command prompt and run: wevtutil gl security
1. Open up a command prompt and run:
wevtutil gl security
This command tells you the current security descriptor for the security event log – specifically in the channelAccess value. The default value is: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
This command tells you the current security descriptor for the security event log – specifically in the channelAccess value. The default value is:
O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
Again, you want to append read access for the Network Service. In my example, your new security descriptor will be: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)
Again, you want to append read access for the Network Service. In my example, your new security descriptor will be:
O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)
2. At the same command prompt, run: wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)
2. At the same command prompt, run:
wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)
Note: This is all one command on the same line.
Configure the Member Server to Collect Events
Now that your server (in my example the Domain Controllers) configuration is complete, you need to configure the member server as the collection point.
1. On the member server that will be collecting the events, open a command prompt and run: winrm qc wecutil qc
1. On the member server that will be collecting the events, open a command prompt and run:
winrm qc
wecutil qc
Answer YES to any prompts you see. The first command (winrm qc) configures the member server to accept WS-Management requests from other machines while the second command (wecutil qc) configures the Windows Event Collector service.
Answer YES to any prompts you see.
The first command (winrm qc) configures the member server to accept WS-Management requests from other machines while the second command (wecutil qc) configures the Windows Event Collector service.
2. At the same command prompt, execute the following command and record the port: winrm enumerate winrm/config/listener
2. At the same command prompt, execute the following command and record the port:
winrm enumerate winrm/config/listener
3. Open the Event Viewer 4. In the left-hand pane, click Subscriptions, then right-click Subscriptions and then left-click Create Subscription. 5. Specify a subscription name and then select Source computer initiated.
3. Open the Event Viewer
4. In the left-hand pane, click Subscriptions, then right-click Subscriptions and then left-click Create Subscription.
5. Specify a subscription name and then select Source computer initiated.
6. Click Select Computer Groups… 7. Click Add Domain Computers… and specify Domain Controllers (or a security group that includes the servers you’re interested in).
6. Click Select Computer Groups…
7. Click Add Domain Computers… and specify Domain Controllers (or a security group that includes the servers you’re interested in).
8. Click OK and OK. 9. Back on the Subscription Properties screen, click Select Events… and specify the events you wish to capture. In my example, I’m looking for logon failures leading to account lockouts. These are logged as event 675 on Windows Server 2003 and event 4771 on Windows Server 2008 / 2008 R2.
8. Click OK and OK.
9. Back on the Subscription Properties screen, click Select Events… and specify the events you wish to capture.
In my example, I’m looking for logon failures leading to account lockouts. These are logged as event 675 on Windows Server 2003 and event 4771 on Windows Server 2008 / 2008 R2.
10. Click OK. 11. Back ok the Subscription Properties screen, click Advanced… and choose Minimize Latency.
10. Click OK.
11. Back ok the Subscription Properties screen, click Advanced… and choose Minimize Latency.
12. Click OK and then OK to close the Subscription Properties screen.
13. Open a command prompt, run: wecutil ss <subscription name> /cm:Custom /dmi:1
13. Open a command prompt, run:
wecutil ss <subscription name> /cm:Custom /dmi:1
Note: This step is only necessary if event collection is time critical.
Policy for Event Forwarding
Having prepared the servers for collection of security events, you now require a Group Policy Object applied to them. This GPO will specify the member server (running Windows Server 2008 or later) where events are collected.
You must create and edit the GPO from a Windows Vista, Windows Server 2008, Windows 7 or Windows Server 2008 R2 system. These are the only operating systems that provide policy settings for Windows Remote Management and Event Forwarding.
In my example, I want security events collected from my Domain Controllers. My member server is member.contoso.com running Windows Server 2008 R2.
1. Open the Group Policy Management Console (GPMC), create a new GPO and link it to the Domain Controllers OU.
2. Right-click the new GPO and open it for editing. 3. In the GPO Editor, navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service 4. In the right-hand pane, open Allow automatic configuration of listeners. 5. Set the policy to Enabled and set the IPv4 and IPv6 filters to *.
2. Right-click the new GPO and open it for editing.
3. In the GPO Editor, navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service
4. In the right-hand pane, open Allow automatic configuration of listeners.
5. Set the policy to Enabled and set the IPv4 and IPv6 filters to *.
6. Click OK. 7. In the GPO Editor, navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Event Forwarding 8. In the right-hand pane, open Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager. 9. Set the policy to Enabled and click Show…. 10. Add the value Server=<member_server>:<port> where <port> is the port recorded earlier.
6. Click OK.
7. In the GPO Editor, navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Event Forwarding
8. In the right-hand pane, open Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager.
9. Set the policy to Enabled and click Show….
10. Add the value Server=<member_server>:<port> where <port> is the port recorded earlier.
11. Click OK and OK. 12. Close the GPO editor. 13. Restart the Windows Remote Management (WS-Management) service on the Domain Controllers. 14. Wait. You need to be patient. Group Policy has to apply, the Windows Remote Management (WS-Management) service on the Domain Controllers has to pick up those policy settings and the Windows Event Collector service on the member server has to start talking to the DCs. Once all of that settles down, you’ll see the events in the Forwarded Events log on the member server.
11. Click OK and OK.
12. Close the GPO editor.
13. Restart the Windows Remote Management (WS-Management) service on the Domain Controllers.
14. Wait. You need to be patient. Group Policy has to apply, the Windows Remote Management (WS-Management) service on the Domain Controllers has to pick up those policy settings and the Windows Event Collector service on the member server has to start talking to the DCs.
Once all of that settles down, you’ll see the events in the Forwarded Events log on the member server.
Conclusion
Now you’re fully prepared to nail down those troublesome problems in environments with high churn security logs!
- Mark ”If it’s there I’ll find it” Renoden
Hiya folks, Ned here again with another week’s questions, comments, and oddities. This time we’re talking:
Let’s get it.
When we change security on our group policies using GPMC, we always get this disturbing message:
“The permissions for this GPO in the SYSVOL folder Are inconsistent with those in Active Directory”
We remove the “Read” and “Apply Group Policy” checkboxes from Authenticated Users by using the Delegation tab in GPMC, then substitute our own specific groups. The policies apply as expected with no errors even when we see this message.
It’s because you are not completely removing the Authenticated Users group. Authenticated Users does not only have “Read” and “Apply Group Policy”, it also has “List Object”, which is a “special” permission. The technique you’re using leaves Authenticated Users still ACL’ed, but with an invalid ACE of just “List”, and that’s what GPMC is sore about:
Instead of removing the two checkboxes, just remove Authenticated Users:
Better yet, don’t use the Delegation tab at all. The Security Filtering section on the main page sets the permissions for read and apply policy, which I presume is what you want. Just remove Authenticated Users and put in X. It gives you the desired resultant policy application, without any errors, and with less effort.
Delegation is designed for controlling who can manipulate policies. It only coincidentally manages who gets policies.
Is it possible to setup multiple ADMT servers and allow both the ability to migrate passwords? I know during the setup of the PES service on a source DC consumes a key file generated from the ADMT server. I wasn’t sure if this ties only allows that server the ability to perform password migrations.
You can always have multiple ADMT copies, as long as they point to the same database; that’s where things tie together, not in ADMT itself. You could use multiple databases, but then you have to keep track of what you migrated in each one and it’s a real mess, especially for computer migration, which works in multiple phases. You’d need multiple PES servers in the source domain and would have to point to the right one from the right ADMT DB instance when migrating users. This is highly discouraged and not a best practice.
I was looking at Warren’s post on figuring out how much DFSR staging space to set aside. I have millions of files, how long can I expect that PowerShell to run? I want to schedule it to go once a week or so, but not if it runs for hours and incinerates the server.
It really depends on your hardware. But for a worst case, I used one of my gross physical test “servers” (it’s really workstation-class hardware) and generated many 1KB files plus 64 1MB files to have something to pick:
The CPU and disk hit was negligible, but the memory usage significantly climbed. I would do this off hours if that server is starved for RAM.
Can USMT migrate files that are longer in locations exceeding MAX_PATH rules of 260 characters?
Both scanstate and loadstate supports paths up to ~32,767 characters, with each “component” (file or folder name) in that path limited to 255 characters.
According to this article, Windows Server 2008 and 2008 R2 DCs use static port 5722 for DFSR. We mainly use Win2008 R2 member servers, so when choosing a port to set DFSR to, should I choose a different port within the range 49152 – 65535? Or would it be OK to set DFSR to 5722 on member servers too, so that all traffic on 5722 will be DFSR regardless of whether it's a DC or a member server involved in the replication?
Totally OK to use 5722 on members and makes your life easier on the firewall config. Make sure you review: http://blogs.technet.com/b/askds/archive/2009/07/16/configuring-dfsr-to-a-static-port-the-rest-of-the-story.aspx
What are the most common Active Directory-related support cases Microsoft gets? I’m planning some training and want to make sure I am hitting the most powerful topics.
In no particular order:
The above five have remained the top issues for 12 years now. Within the rest of Directory Services support, ADFS and PKI have seen the most growth in the past year.
In case you live on the Mariana Islands and only got your first Internet connection today, we’ve started talking about Windows 8. Shiny pictures and movies too.
Preemptive strike: I cannot talk about Windows 8.
The power of inspirational infographics, via the awesome datavisualization.ch and from the brilliant H57 Design:
The Cubs were robbed.
It’s time for IO9 2011 fall previews of science fiction and fantasy:
We released the Windows 7 theme you’ve been wanting, Jonathan!
Is this the greatest movie ever created? Certainly one of the most insane. It’s safe for work.
Unless you work in an anthropomorphic cannibalism outreach center
And finally, from an internal email thread discussing some new support case assignment procedures:
From: a manager To: all DS support staff at MicrosoftSubject: case assignment changes
For cases that are dispatched to the Tier 3 queue and assigned based on an incorrect support topic or no support topic listed. Engineers will do the following:
1. Set appropriate Support topic 2. Update the SR Title-with: STFU\[insert new skill here] 3. Correct support topic for assignment 4. Dispatch the case back to the queue for re-assignment
1. Set appropriate Support topic
2. Update the SR Title-with: STFU\[insert new skill here]
3. Correct support topic for assignment
4. Dispatch the case back to the queue for re-assignment
Five minutes later:
From: a manager To: all DS support staff at Microsoft Subject: RE: case assignment changes
Incidentally, the acronym STFU stands for “Support Topic Field Update” :-)
Have a nice weekend, folks.
Ned “the F is for Frak” Pyle
Hi, Mike here again. Today, I want to write about a common administrative task that can lead to disaster: removing stale computer accounts from Active Directory.
Removing stale computer accounts is simply good hygiene-- it’s the brushing and flossing of Active Directory. Like tartar, computer accounts have the tendency to build up until they become a problem (difficult to identify and remove, and can lead to lengthy backup times).
Many environments separate administrative roles. The Active Directory administrator is not the Cluster Administrator. Each role holder performs their duties in a somewhat isolated manner-- the Cluster admins do their thing and the AD admins do theirs. The AD admin cares about removing stale computer accounts. The cluster admin does not… until the AD admin accidentally deletes a computer account associated with a functioning Failover Cluster because it looks like a stale account.
Unexpected deletion of Cluster Name Object (CNO) or Virtual computer Object (VCO) is one of the top issues worked by our engineers that support Clustering and High-Availability. Everyone does their job and boom-- Clustered Servers stop working because CNOs or the VCOs are missing. What to do?
I'll paraphrase an article posted on the Clustering and High-Availability TechNet blog that solves this scenario. Typically, domain admins key on two different attributes to determine if a computer account is stale: pwdlastSet and LastLogonTimeStamp. Domains that are not configured to a Window Server 2003 Domain Functional Level use the pwdLastAttribute. However, domains configured to a Windows Server 2003 Domain Functional Level or later should use the lastLogonTimeStamp attribute. What you may not know is that a Failover Cluster (CNO and VCO) does not update the lastLogonTimeStamp the same way as a real computer.
Cluster updates the lastLogonTimeStamp when it brings a clustered network name resource online. Once online, it caches the authentication token. Therefore, a clustered network named resource working in production for months will never update the lastLogonTimeStamp. This appears as a stale computer account to the AD administrator. Being a good citizen, the AD administrator deletes the stale computer account that has not logged on in months. Oops.
There are few things that you can do to avoid this situation.
Mike "Four out of Five AD admins recommend ASKDS" Stephens
Hiya folks, Ned back with a palette-cleansing Mail Sack after this monstrosity. This week we talk about:
Let’s get swimmy-headed.
I'm curious to get your feedback on custom AD Schema extensions – those that are created "in house" for a specific need. What is the overall Microsoft stance on the topic? Should we do it, or use AD LDS? We have an app we’re designing and want to do this the “right” way.
It’s always “safer” to use AD/LDS - as it’s easier to throw that away and start over - but as long as you follow our best practices, we don’t get too bent out of shape if you extend your schema. That’s what it’s there for. The critical piece is that you get your base OID from ISO, or barring that, generate one using our safe script. You can also use proxy accounts to tie AD and ADLDS together, the way that we always intended but which never really caught on.
Some of the best practices:
The tricky part of extending your AD schema is no matter how carefully you do it, some millet-for-brains vendor may not. Then you buy their product and cannot use it, due to duplicate attributes or classes. It’s a lot simpler to fix an AD/LDS schema than your AD forest schema.
Hold payment on the vendor’s check until you are sure it works in your lab.
When we deploy Domain Controllers in our environment (whether its a RWDC or RODC, they all run DNS) we always remove our Root Hints. We do this on our RODCs after the DCPROMO and before the reboot. Is there anyway to remove the Root Hints after the RODC becomes read-only?
There’s nothing special as part of the RODC promotion process itself that would let you do this, as DNS configuration is quite restricted when you let the DC process handle it. You have a couple workarounds:
1. Configure the root hints via its registry value “isslave”, perhaps run as a batch at the end of promotion. See KB2001154 for more info on configuring this. And no snickering at this Win2008 bug in the comments! Ok, maybe a little. 2. Don’t have the RODC install and configure DNS (in an unattend install, this is “SkipAutoConfigDNS”). Script the DNS installation using DNSCMD to do everything. This seems like overkill, but answers the greater question of controlling RODC+DNS configuration.
1. Configure the root hints via its registry value “isslave”, perhaps run as a batch at the end of promotion. See KB2001154 for more info on configuring this. And no snickering at this Win2008 bug in the comments! Ok, maybe a little.
2. Don’t have the RODC install and configure DNS (in an unattend install, this is “SkipAutoConfigDNS”). Script the DNS installation using DNSCMD to do everything. This seems like overkill, but answers the greater question of controlling RODC+DNS configuration.
It’s critically important to note:
http://support.microsoft.com/kb/818020 Note Microsoft does not support the removal of all root hints from a Microsoft DNS server. A Microsoft DNS server must have at least one root hint. However, you can replace the existing root hints with new root hints. When you replace root hints, the change is permanent, and the old root hints do not reappear. If the DNS server if forwarding, click to select the Do not use recursion for this domain check box on the Forwarders tab in DNS Manager to make sure that the root hints will not be used.
http://support.microsoft.com/kb/818020
Note Microsoft does not support the removal of all root hints from a Microsoft DNS server. A Microsoft DNS server must have at least one root hint. However, you can replace the existing root hints with new root hints. When you replace root hints, the change is permanent, and the old root hints do not reappear. If the DNS server if forwarding, click to select the Do not use recursion for this domain check box on the Forwarders tab in DNS Manager to make sure that the root hints will not be used.
We are performing a USMT migration. On the source machine we generate the config.xml file by using the genconfig switch and we specify the migapp.xml file in the command line.
Scanstate.exe /genconfig:config.xml /i:migapp.xml
This way we can decide if we want to block certain apps from migrating without changing the migapp.xml.
We have Itunes listed in the xml file as well as the application installed on the machine. But it never gets listed in the config.xml file. I’m missing other applications that TechNet says are supported.
It’s because you have newer, “unsupported” versions of the apps installed – note how the MIGAPP.XML starts each section with a <detect>. For example, here are WinZip and Adobe Reader:
If Adobe Reader 9.X and WinZip 8.*-10.* are installed, they will manifest and migrate:
But if I have the latest Adobe Reader (10.*) and WinZip (15.*) installed, they are not detected and therefore, will not manifest or migrate:
To be more supported by the vendor is to be less supported by USMT as time goes by.
You have several options:
1. Convince the vendor of the USMT-unsupported apps to give you updated migration XML. They submitted the previous version requirements for their own app during the USMTdevelopment process – that’s why so few apps are listed and they are so esoteric: Winzip but not WinRar? RealPlayer but not WinAmp? AD-Aware but not a hundred other anti-spyware apps? Microsoft didn’t create the list. 2. Create a copy of the migapp.xml, add detection elements for those newer versions and update any paths necessary, and validate that they see seem to migrate the right settings. Then migrate using that updated XML instead of the shipping XML and cross your fingers, because you are hoping you got it all right and your vendor is going to support it (Microsoft does not care – again, these are not our settings). 3. Migrate older versions of the apps, then update them after the fact (included only for completeness’ sake – this is extremely gross)
1. Convince the vendor of the USMT-unsupported apps to give you updated migration XML. They submitted the previous version requirements for their own app during the USMTdevelopment process – that’s why so few apps are listed and they are so esoteric: Winzip but not WinRar? RealPlayer but not WinAmp? AD-Aware but not a hundred other anti-spyware apps? Microsoft didn’t create the list.
2. Create a copy of the migapp.xml, add detection elements for those newer versions and update any paths necessary, and validate that they see seem to migrate the right settings. Then migrate using that updated XML instead of the shipping XML and cross your fingers, because you are hoping you got it all right and your vendor is going to support it (Microsoft does not care – again, these are not our settings).
3. Migrate older versions of the apps, then update them after the fact (included only for completeness’ sake – this is extremely gross)
You’ll have this issue even if you don’t generate config.xml file, naturally.
I am looking to replicate a folder under the “Windows” folder via DFSR. I found this article http://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx
"When replicating a volume that contains the Windows system folder, DFS Replication recognizes the %WINDIR% folder and does not replicate it.
I was wondering if there is any workaround for this, so we can replicate something under the c:\Windows folder.
There is no way around this – it is by design and very intentional. Replicating something under %windir% makes me think you want to synchronize things like drivers between servers, which is a no-no. If you try, you get this DFSR event:
Event ID=6410 Severity=Error The DFS Replication service failed to initialize replicated folder %2 because the service detected that one of its working folders overlaps a Windows system folder. This is an unsupported configuration. Additional Information: Overlapped Folder: %3 Replicated Folder: %4 Replicated Folder Name: %5 Replicated Folder ID: %1 Replication Group Name: %6 Replication Group ID: %7 Member ID: %8 System Folder:%9
Event ID=6410 Severity=Error The DFS Replication service failed to initialize replicated folder %2 because the service detected that one of its working folders overlaps a Windows system folder. This is an unsupported configuration.
Additional Information: Overlapped Folder: %3 Replicated Folder: %4 Replicated Folder Name: %5 Replicated Folder ID: %1 Replication Group Name: %6 Replication Group ID: %7 Member ID: %8 System Folder:%9
You cannot use DFSR to replicate %systemroot% folders, except for the special case of SYSVOL on Win2008+ DCs.
And while we’re on the subject: while this does not also check %programfiles%, %ProgramFiles(x86)%, or the hidden %programdata%, replicating those folders is just as likely to cause massive issues, to possibly include an unbootable server if you are especially unlucky. Move your data elsewhere.
After discussing the "DC DNS A Records and Web Servers" question from Friday's Mail Sack with my co-workers, I have a question about that question. Let’s say someone changed their (same as parent folder) A record to point at the Virtual IP of a hardware load balancer. This VIP would serve as a content switch that looks at traffic like this: Are you destined for port 80 or 443? If YES -> redirect traffic to web server If NO -> redirect to 1 of x domain controllers. Is this a viable solution?
The DNS folks and I discussed this option when I was vetting the previous post, and we ultimately decided that it would need some kind of third party device that Microsoft doesn’t make – so we could not speak to its viability, as we had no visibility. In addition, there are legitimate reasons to connect to a DC over web ports – the AD Management Gateway/AD Web Service uses HTTP/HTTPS traffic in order to allow you to use AD PowerShell, for example. So drawing the line would be tricky.
Now I answered on the intornotz so I guess the cat’s out of the bag.
What are the correct settings for DFS Namespace to make client failover occur more quickly? I have tried different cache timeout settings but it always seems to take about 30-45 seconds to get access to files again if a DFS target share goes offline.
The issue isn’t DFSN; it’s the Redirector and SMB. Since you already had a connection to that server, the redirector tries to reconnect to it in case there was only a temporary network outage –it’s just a UNC path to a share at that point. The same happens if you point to a single share on a single server, and take that server offline – Windows Explorer doesn’t instantly give you an error that the server is unavailable. A network capture shows bursts of “retry” SMB traffic from that client until it finally gives up and says the server is not coming back. This behavior dates back to NT:
148950 Changing the Windows NT Redirector Time-Out Value http://support.microsoft.com/default.aspx?scid=kb;EN-US;148950
(This registry value isn’t applicable to later OSes; we decided allowing adjustment caused too many issues)
The caching doesn’t change in this scenario either – nothing has changed for the actual link targets in the referral. When SMB gets tired of trying, you move to the next entry in the cache. I can set my client cache timeout to 5 seconds and still see the Redirector sending out retry SMB packets for 30-45 seconds.
The DFSN client connectivity design isn’t for instant failover; it’s for geographical high availability and closest targeting. If you need instant failover, clustering is the way to go. Since the server and connection never goes away due to cluster magic, your users will not see noticeable delays.
If you want the Mack of all solutions, cluster your DFSN link targets. At the very least, your hardware sales rep will appreciate it; he can now afford that Virage he’s been eyeing…
If I search for an object against an AD LDS instance that I know is in AD DS, I get: Error 0x20D6 No superior reference has been configured for the directory service. The AD LDS Server is joined to the AD DS forest that the object I'm searching for is in (I have an application that needs to be restricted to looking at AD LDS, but also have AD LDS send off objects to AD DS that AD LDS cannot find). I found this article, but it doesn't provide any examples of how to configure a crossRef or superior reference, so I'm a little lost.
You have to configure attribute superiorDnsRoot on the configuration partition crossref object. You can use this technique, but use the AD/LDS config partition path.
That error in AD/LDS instance can also mean:
Very generic as you can see. If the above KB doesn’t work, I suggest opening a support case to let us really dig in.
I’ve been teaching the past few weeks and a number of students commented on my rotating Windows 7 wallpaper of mecha. They were all downloaded from the amazing online art site ConceptRobots. They have thousands of these, in many styles. Check out a small sampling:
Go there only if you have hours to waste
We just installed a Coke Freestyle machine at work and it’s seriously cool. I’ve never seen a line at the soda fountain before, and ours are free. You should come see for yourself. Those students admiring my wallpaper were 33 new hires right here in Charlotte.
Like baseball? Add this to your favorites. Not the prettiest site, but if you want amazing details, statistics, and stories, it’s the best.
And finally - I was sitting at a light last week when I noticed this fella. It really sums up my eleven years of living in North Carolina and that my wife is right - I’m still just a damyankee:
Ford F-150, even though he lives in an affluent suburb – check Aftermarket U-Haul tow-hitch - check Vanity plate with Larry the Cable Guy catchphrase – check Bumper sticker affirming that this is not the smallest pickup he will ever own – check But the icing on the cake: He bought the truck from NASCAR racing driver Dale Jarrett. Hells yeah.
Ford F-150, even though he lives in an affluent suburb – check
Aftermarket U-Haul tow-hitch - check
Vanity plate with Larry the Cable Guy catchphrase – check
Bumper sticker affirming that this is not the smallest pickup he will ever own – check
But the icing on the cake:
He bought the truck from NASCAR racing driver Dale Jarrett. Hells yeah.
Have a great weekend folks.
Ned “the ethernet cable guy” Pyle
Hello AskDS readers, it's Mike again talking about Group Policy Preference targeting items. I posted an article in June entitled Targeting Group Policy Preferences by Container, not by Group. This post highlighted the common problems many people encounter when targeting preferences items based on a computer's group membership, why the problem occurs, and some workarounds.
Today, I'd like to introduce a hotfix released by Microsoft that improves targeting preference items by computer group membership. The behavior before the hotfix potentially resulted in slow computer group policy application. The slowness was caused by the way Security Group targeting applies against a computer account. The targeting item makes multiple round trips to a domain controller to determine group memberships (including nested groups). The slowness is more significant when the computer applying the targeting item does not have a local domain controller and must use a domain controller across a WAN link.
You can download the hotfix for Windows 7 and Windows Server 2008 R2 through Microsoft Knowledgebase article 2561285. This hotfix changes how the Security Group Targeting item calculates computer group membership. During policy application, the targeting item requests a copy of the computer's authentication token. This token is mostly identical to the token created during logon, which means it contains a list security identifiers (SIDs) for every group of which the computer is a member, including nested groups. The targeting item performs the configured comparison against this list of SIDs in the token, rather than multiple LDAP calls to a domain controller. This behavior aligns the behavior of computer security group targeting with that of user security group targeting. This should improve the performance of security group targeting.
Mike "Try, Try, Try Again" Stephens
This part covers the following config.xml components for Windows Vista:
--------------------------------------------------------------------------------------------------
<component displayname="Microsoft-Windows-RPC-HTTP" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rpc-http/microsoft-windows-rpc-http/settings"/>
<component displayname="Microsoft-Windows-RasMprDdm" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rasmprddm/microsoft-windows-rasmprddm/settings"/>
<component displayname="Microsoft-Windows-RasBase" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rasbase/microsoft-windows-rasbase/settings"/>
<component displayname="Microsoft-Windows-Microsoft-Data-Access-Components-(MDAC)-ODBC-DriverManager-Dll" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-microsoft-data-access-components-(mdac)-odbc-drivermanager-dll/microsoft-windows-microsoft-data-access-components-(mdac)-odbc-drivermanager-dll/settings"/>
<component displayname="Microsoft-Windows-ICM-Profiles" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-icm-profiles/microsoft-windows-icm-profiles/settings"/>
<component displayname="Microsoft-Windows-feclient" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-feclient/microsoft-windows-feclient/settings"/>
<component displayname="Microsoft-Windows-dpapi-keys" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-dpapi-keys/microsoft-windows-dpapi-keys/settings"/>
<component displayname="Microsoft-Windows-Crypto-keys" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-crypto-keys/microsoft-windows-crypto-keys/settings"/>
<component displayname="Microsoft-Windows-COM-DTC-Setup" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-com-dtc-setup/microsoft-windows-com-dtc-setup/settings"/>
<component displayname="Microsoft-Windows-COM-ComPlus-Setup" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-com-complus-setup/microsoft-windows-com-complus-setup/settings"/>
<component displayname="Microsoft-Windows-COM-Base" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-com-base/microsoft-windows-com-base/settings"/>
<component displayname="Microsoft-Windows-CAPI2-certs" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-capi2-certs/microsoft-windows-capi2-certs/settings"/>
</component>
<component displayname="Accessibility" migrate="yes" ID="accessibility">
<component displayname="Accessibility Settings" migrate="yes" ID="accessibility\accessibility_settings">
<component displayname="Microsoft-Windows-accessibilitycpl" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-accessibilitycpl/microsoft-windows-accessibilitycpl/settings"/>
C:\Windows\winsxs\Manifests\x86_microsoft-windows-rpc-http_31bf3856ad364e35_6.0.6002.18005_none_a1e465fc3c75b4fa.manifest
Migrates per-computer HTTP over RPC customization only for value "UseProxyForIPAddrIfRDNSFails" as defined in http://msdn.microsoft.com/en-us/library/aa373592(VS.85).aspx. There is no UI for this setting.
<component displayname="Microsoft-Windows-Rasppp" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rasppp/microsoft-windows-rasppp/settings"/>
\USMT\x86\ReplacementManifests\RASPPP-REPL.MAN
Migrates portions of the per-computer RAS PPP settings. There is no UI for these settings.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-rasmprddm_31bf3856ad364e35_6.0.6001.18000_none_99165124cd984b96.manifest
Migrates portions of the per-computer RAS service authentication settings. There is no UI for these settings.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-rasbase_31bf3856ad364e35_6.0.6002.18005_none_0fcbe0ed77911065.manifest
Migrates portions of the per-computer RAS service IP settings. There is no UI for these settings.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-m..c-drivermanager-dll_31bf3856ad364e35_6.0.6002.22555_none_1271c00d00610f35.manifest
Migrates per-user and per-computer files and registry settings for ODBC. Note that 32-bit ODBC application settings are not migrated from x64 source computers (see example manifest on X64 vista, such as: amd64_microsoft-windows-m..c-drivermanager-dll_31bf3856ad364e35_6.0.6002.18005_none_6e3cc6c99f786050.manifest), due to an oversight in the manifests.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-icm-profiles_31bf3856ad364e35_6.0.6000.16386_none_9728ca2d08c669b6.manifest
Migrates per-user and per-computer color management customizations.
C:\Windows\winsxs\Manifests \x86_microsoft-windows-accessibilitycpl_31bf3856ad364e35_6.0.6002.18005_none_5b4939df50fd5bc7.manifest
Migrates per-user and per-computer accessibility customizations.
<component displayname="Microsoft-Windows-TabletPC-UIHub" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabletpc-uihub/microsoft-windows-tabletpc-uihub/settings"/>
C:\windows\winsxs\manifests\x86_microsoft-windows-tabletpc-uihub_31bf3856ad364e35_6.0.6001.18000_none_138913239c3640a9.manifest
Migrates per-user and per-computer tablet pen settings.
<component displayname="Microsoft-Windows-TabletPC-Platform-Input-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-tabletpc-platform-input-core/microsoft-windows-tabletpc-platform-input-core/settings"/>
\USMT\x86\ReplacementManifests\TABLETPCPLATFORMINPUT-CORE-REPLACEMENT.MAN
Migrates per-user and per-computer tablet input settings (some redundant to TABLETPC-UIHUB-REPLACEMENT.MAN).
<component displayname="Microsoft-Windows-Rights-Management-Client-v1-API" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rights-management-client-v1-api/microsoft-windows-rights-management-client-v1-api/settings"/>
\USMT\x86\ReplacementManifests\RIGHTS-MANAGEMENT-CLIENT-V1-API-REPLACEMENT.MAN
Ned “better than counting sheep” Pyle
<component displayname="Additional Options" migrate="yes" ID="additional_options">
<component displayname="Help Settings" migrate="yes" ID="additional_options\help_settings">
<component displayname="Microsoft-Windows-Help-Client" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-help-client/microsoft-windows-help-client/settings"/>
<component displayname="Windows Core Settings" migrate="yes" ID="additional_options\windows_core_settings">
<component displayname="Microsoft-Windows-Win32k-Settings" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-win32k-settings/microsoft-windows-win32k-settings/settings"/>
<component displayname="Microsoft-Windows-Web-Services-for-Management-Core" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-web-services-for-management-core/microsoft-windows-web-services-for-management-core/settings"/>
<component displayname="Microsoft-Windows-UPnPSSDP" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-upnpssdp/microsoft-windows-upnpssdp/settings"/>
<component displayname="Microsoft-Windows-UPnPDeviceHost" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-upnpdevicehost/microsoft-windows-upnpdevicehost/settings"/>
<component displayname="Microsoft-Windows-UPnPControlPoint" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-upnpcontrolpoint/microsoft-windows-upnpcontrolpoint/settings"/>
<component displayname="Microsoft-Windows-TerminalServices-RemoteConnectionManager" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-terminalservices-remoteconnectionmanager/microsoft-windows-terminalservices-remoteconnectionmanager/settings"/>
<component displayname="Microsoft-Windows-TerminalServices-Drivers" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-terminalservices-drivers/microsoft-windows-terminalservices-drivers/settings"/>
<component displayname="Microsoft-Windows-SQMApi" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-sqmapi/microsoft-windows-sqmapi/settings"/>
<component displayname="Microsoft-Windows-RPC-Remote" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rpc-remote/microsoft-windows-rpc-remote/settings"/>
<component displayname="Microsoft-Windows-RPC-Local" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-rpc-local/microsoft-windows-rpc-local/settings"/>
C:\Windows\winsxs\Manifests\x86_microsoft-windows-help-client_31bf3856ad364e35_6.0.6001.18000_none_6c1890222e16b0ed.manifest
Migrates per-user Help customizations, such as size, layout, and online updates.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-win32k-settings_31bf3856ad364e35_6.0.6002.18005_none_b326fbadff7217f6.manifest
Migrates a variety of per-computer settings, such as default font, CMD prompt sizes, and shutdown warning timers (most settings have no UI). Also migrates per-user input and display settings like mouse options and dialog colors (with many exceptions for hardware specific and OS specific settings, such as monitor resolution and screensavers).
C:\Windows\winsxs\Manifests\x86_microsoft-windows-w..for-management-core_31bf3856ad364e35_7.0.6001.18181_none_bb807475382e6b2a.manifest
plugin file="$(runtime.system32)\WSManMigrationPlugin.dll"
Migrates per-computer WINRM (Windows Remote Management) settings. There is no graphical UI for these settings, they are configured via winrm.exe command-line tool.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-upnpssdp_31bf3856ad364e35_6.0.6000.16386_none_7d92b0efd44d38e1.manifest
Migrates certain per-computer Simple Service Discovery Protocol service parameters. There is no UI for these settings.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-upnpdevicehost_31bf3856ad364e35_6.0.6001.18000_none_c1e834753483fdcf.manifest
Migrates per-computer UPnP Device Host service settings. No UI for these settings, configured via the device software.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-upnpcontrolpoint_31bf3856ad364e35_6.0.6001.18000_none_32cf6e4430c13212.manifest
Migrates a subset of per-computer UPnP Control Point settings. There is no UI for these settings.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-t..teconnectionmanager_31bf3856ad364e35_6.0.6002.18005_none_908abad45165e2ae.manifest
Migrates per-computer default connection settings for remote desktop sessions to the computer. There is no UI for this on Windows Vista (it is usually configured by the remote Desktop Session Host Configuration snap-in on Windows Server 2008)
C:\Windows\winsxs\Manifests\x86_microsoft-windows-t..nalservices-drivers_31bf3856ad364e35_6.0.6001.18000_none_51501845f67a4a0e.manifest
Migrates the per-computer remote desktop listener being enabled or disabled. There is no UI for this on Windows Vista (it is usually configured by the remote Desktop Session Host Configuration snap-in on Windows Server 2008)
C:\Windows\winsxs\Manifests\x86_microsoft-windows-sqmapi_31bf3856ad364e35_6.0.6001.18000_none_fe3db30d04ce3dab.manifest
Migrates the per-computer unattended settings for the SQM (Windows telemetry reporting) client. There is no UI for this setting and by default, the migrated registry key does not exist.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-rpc-remote_31bf3856ad364e35_6.0.6000.16386_none_be6271493635f7fa.manifest
Migrate per-computer remote RPC port customizations as defined in http://support.microsoft.com/kb/154596. No UI for these settings.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-rpc-local_31bf3856ad364e35_6.0.6002.22120_none_b65513a45b6873a4.manifest
Migrates per-computer local RPC port customizations. There is no UI for these settings, they do not exist by default, and they are not publically documented.
<component displayname="Security" migrate="yes" ID="security">
<component displayname="Security Options" migrate="yes" ID="security\security_options">
<component displayname="Microsoft-Windows-Credential-Manager" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-credential-manager/microsoft-windows-credential-manager/settings"/>
<component displayname="Appearance and Display" migrate="yes" ID="appearance_and_display">
<component displayname="Windows Games Settings" migrate="yes" ID="appearance_and_display\windows_games_settings">
<component displayname="Microsoft-Windows-GameExplorer" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-gameexplorer/microsoft-windows-gameexplorer/settings"/>
<component displayname="Taskbar and Start Menu" migrate="yes" ID="appearance_and_display\taskbar_and_start_menu">
<component displayname="Microsoft-Windows-stobject" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-stobject/microsoft-windows-stobject/settings"/>
<component displayname="Microsoft-Windows-explorer" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-explorer/microsoft-windows-explorer/settings"/>
<component displayname="Personalized Settings" migrate="yes" ID="appearance_and_display\personalized_settings">
<component displayname="Microsoft-Windows-uxtheme" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-uxtheme/microsoft-windows-uxtheme/settings"/>
<component displayname="Microsoft-Windows-themeui" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-themeui/microsoft-windows-themeui/settings"/>
<component displayname="Microsoft-Windows-shell32" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-shell32/microsoft-windows-shell32/settings"/>
<component displayname="Microsoft-Windows-CommandPrompt" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-commandprompt/microsoft-windows-commandprompt/settings"/>
Migrates per-user and per-computer DRM settings. There is no UI for these settings.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-credential-manager_31bf3856ad364e35_6.0.6000.16386_none_a527dc6f9f86ae33.manifest
Migrates certain per-computer credman security settings and per-user stored credentials (not cached interactive logon creds).
C:\Windows\winsxs\Manifests\x86_microsoft-windows-gameexplorer_31bf3856ad364e35_6.0.6002.22475_none_4429bb23d7b5279d.manifest
Migrates per-computer and per-user Game Explorer settings and statistics.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-stobject_31bf3856ad364e35_6.0.6000.16386_none_47ec33cd5890f3d2.manifest
Migrates customized power management notification area settings. These can only be set through group policy or direct registry editing. This has nothing to do with the actual power management settings.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-explorer_31bf3856ad364e35_6.0.6000.16386_none_4f7de5167cd15deb.manifest
Migrates per-user Windows Explorer settings to include taskbar, folder options, notification area, and other shell preferences.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-uxtheme_31bf3856ad364e35_6.0.6001.18000_none_a5e49ad4068f9b12.manifest
Migrates per-user current appearance scheme selection.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-themeui_31bf3856ad364e35_6.0.6002.18005_none_86ea0f7f18a2f487.manifest
Migrates per-user customizations made to the currently selected theme.
<component displayname="Microsoft-Windows-shmig" migrate="yes" ID="http://www.microsoft.com/migration/1.0/migxmlext/cmi/microsoft-windows-shmig/microsoft-windows-shmig/settings"/>
\USMT\x86\ReplacementManifests\SHMIG-REPLACEMENT.MAN
plugin file="Microsoft-Windows-shmig\shmig.dll"
There is no practical XML for this manifest, all work done by the plugin SHMIG. It loads each user profile and migrates registry settings for per-user display settings like DPI, wallpaper, screensaver settings, recycle bin usage and confirmation dialogs, the Start Menu, and User Tiles.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-shell32_31bf3856ad364e35_6.0.6002.22574_none_6e51988f2874f7b1.manifest
Migrates per-user shell icon settings and screen positions.
C:\Windows\winsxs\Manifests\x86_microsoft-windows-commandprompt_31bf3856ad364e35_6.0.6001.18000_none_8b0cc6bd1a5c896f.manifest
Migrates select CMD prompt defaults per-user and per-default user, such as the default auto-completion character. There is no UI for these settings, only registry.