Friday Mail Sack: Barbados Edition
Published Apr 04 2019 04:34 PM 434 Views
First published on TechNet on Sep 17, 2010
Hello world, Ned here again. I’m back to write this week’s mail sack – just in time to be gone for the next two weeks on vacation and work travel . In the meantime Jonathan and Scott will be running the show, so be sure to spam the heck out of them with whatever tickles you. This week we discuss DFSR, Certificates, PKI, PowerShell, Audit, Infrastructure, Kerberos, NTLM, Active Directory Migration Tool, Disaster Recovery, and not-art.

Catluck en ’ dogluck!


I need to understand what the difference between the various AD string type attribute syntaxes are. From : String(Octet), String(Unicode), Case-Sensitive String, String(Printable), String(IA5) et al. While I understand each type represents a different way to encode the data in the AD database, it isn't clear to me:

  1. Why so many?

  2. What differences are there in managing/using/querying them?

  3. If an application uses LDAP to update/read an attribute of one string type, is it likely to encounter issues if the same routine is used to update/read a different string type?


Active Directory has to support data-storage needs for multiple computer systems that may use different standards for representing data. Strings are the most variable data to be encoded because one has to account for different languages, scripts, and characters. Some standards limit characters to the ANSI character set (8-bit) while others specify another encoding type altogether (IA5 or PrintableString for X.509, for example).

Since Active Directory needs to store data suitable for all of these various systems, it needs to support multiple encodings for string data.

Management/query/read/write differences will depend very much on how you access the directory. If you use PowerShell or ADSI to access the directory, some level of automation is involved to properly handle the syntax type. PowerShell leverages the System.String class of the .NET Framework which handles, pretty much invisibly, the various string types.

Also, when we are talking about the 255-character extended ANSI character set, which includes the Latin alphabet used in English and most European Languages, then the various encodings are pretty much identical. You really won't encounter much of a problem until you start working in 2-byte character sets like Kanji or other Eastern scripts.


Is it possible / advisable to run the CA service under an account different from SYSTEM with EFS enabled for some files that should not be read by system or would another solution be more appropriate?


No, running the CA service under any account other than Network Service is not supported. Users who are not trusted for Administrator access to the server should not be granted those rights.

[PKI and string type answers courtesy of J onathan Stephens, the “Blaster” in our symbiotic “ Master Blaster” relationship – Ned]


Tons of people asking us about this article and if it is true or false or confused or what.


It’s complicated and we’re getting this ironed out. Jonathan is going to create a whole blog post on how User Kerberos can function perfectly without a Kerberos Trust, or with an NTLM trust, or with no trust. It’s all smoke and mirrors basically – you don’t need a trust in all circumstances to use User Kerberos. Heck, don’t even have to use a domain-joined computer. For now, disregard that article please.


I followed the steps outlined in this blog post: . Works like a champ and I see the data correctly in the Event Viewer . But when I try to use PowerShell 2.0 on one of those Win2003 DC’s with this syntax:
Get-EventLog -logname security -Newest 1 -InstanceId 566 | Where-Object { $_.entrytype -match "Success" } | Format-List

A bunch of the outputs are broken and unreadable (they look like un-translated GUID’s and variables). Like Object Type and Object Name, for example:


Ick, I can repro that myself.

This appears to be an issue in PowerShell 2.0 Get-EventLog cmdlet on Win2003 where an incorrect value is being displayed. You can’t have the issue on Win2008/2008 R2, I verified. Hopefully one of our Premier contract customers will report this issue so we can investigate further and see what the long term fix options are.

In the meantime though, here’s some sample workaround code I banged up using an alternative legacy cmdlet Get-WmiObject to do the same thing (including returning the latest event only, which makes this pretty slow):
Get-WmiObject -query "SELECT * FROM Win32_NTLogEvent Where Logfile = 'Security' and EventCode=566" | sort timewritten –desc | select –first 1

Slower and more CPU intensive, but it works.

A better long term solution (for both auditing and PowerShell) is get your DC’s running Win2008 R2.


Do you have suggestions for pros/cons on breaking up a large DFSR replication group? One of our many replication groups has only one replicated folder. Over time that folder has gotten to be a bit large with various folders and shares (hosted as links) nested within. Occasionally there are large changes to the data and the replication backlog obviously impacts the ENTIRE folder. I have thought about breaking the group into several individual replication folders, but then I begin to shudder at the management overhead and monitoring all the various backlogs, etc.

  1. Is there a smooth way to transition an existing replication group with one replicated folder into one with many replicated folders? By "smooth" I mean no disruption to current replication if at all possible, and without re-replicating the data.

  2. What are the major pros/cons on how many replicated folders a given group has configured?


There’s no real easy answer – any change of membership or replicated folder within an RG means a re-synch of replication; the boundaries are discrete and there’s no migration tool. The fact that a backlog is growing won’t be helped by more or fewer RG/RF combos though, unless the RG/RF’s now involve totally different servers . Since the DFSR service’s inbound/outbound file transfer model is per server , moving things around locally doesn’t change backlogs significantly*.


  1. No way to do this without total replication disruption (as you must rebuild the RG’s/RF’s in DFSR from scratch; the only saving grace here is if you don’t have to move data, you would get some pre-seeding for free).

  2. Since each RF would still have a staging/conflictanddeleted/installing/deleted folder each, there’s not much performance reasoning behind rolling a bunch of RF’s into a single RG. And no, you cannot use a shared structure. :) The main piece of an RG is administrative convenience: delegation is configured at an RG level for example, so if you had a file server admin that ran all the same servers that were replicating… stuff… it would be easier to organize those all as one RG.

* As a regular reader though, I imagine you’ve already seen this, which has some other ways to speed things up; that may help some of the choke ups:


Is there an Add-QADPermission (from Quest ) equivalent command is in AD PowerShell?


There is not a one-to-one cmdlet. But it can be done:

It is – to be blunt – a kludge in our current implementation.


I am working on an inter-forest migration that will involve a transitional forest hop. If I have to move the objects a second time to get them from a transition forest into our forest then will I lose the original SID History that is in the SID History attribute.?


You will end up with multiple SID history entries. It’s not an uncommon scenario to see customers would have been through multiple acquisitions and mergers end up with multiple SID histories. As far as authorization goes, it works fine and having more than one is fine:

Contains previous SIDs used for the object if the object was moved from another domain. Whenever an object is moved from one domain to another, a new SID is created and that new SID becomes the objectSID. The previous SID is added to the sIDHistory property.

The real issue is user profiles. You have to make sure that ADMT profile translation is performed so that after users and computers are migrated the ProfileList registry entries are updated to use the user’s real current SID info. If you do not do this, when you someday need to use USMT to migrate data it will fail as it does not know or care about old SID history, only the SID in the profile and the current user’s real SID.

And then you will be in a world of ****.

Picture courtesy of the IRS


Do you know if there is any problem with creating a DNS record with the name ldap name? Or maybe there will be some problems with other components of Active Directory if there is a record called “LDAP”?


Windows certainly will not care and we’ve had plenty of customers use that specific DNS name. We keep a document of reserved names as well, so if you don’t see something in this list, you are usually in good shape from a purely Microsoft perspective:
909264  Naming conventions in Active Directory for computers, domains, sites, and OUs;EN-US;909264

This article is also good for winning DNS-related bar bets. If you drink at a pub called “The Geek and Spanner”, I suppose…

This is not that pub


I'm currently working on a migration to Windows Server 2008 R2 AD forest – specifically the Disaster Recovery plan. Is it good idea to take one of the DCs offline, and after every successful "adprep operation" bring it back online? Or in case if something will go bad use this offline one to recreate domain?


The best solution is to put these plans in place:
Planning for Active Directory Forest Recovery

That way no matter what happens under any circumstances (not just adprep), you have a way out. You can’t imagine how many customers we deal with every day that have absolutely no AD Disaster Recovery system in place at all.


How did you make this kind of picture in your DFSR server replacement series ?

[From a number of readers]


MS Office to the rescue for a non-artist like me. This is a modified version of the “relaxed perspective” picture format preset.

1. Create your picture, then select it and use the Picture Tools Format ribbon tab.

2. Use the arrows to see more of the style options, and you’ll see the one called “Relaxed Perspective, White”. Select that and your picture will now look like a three dimensional piece of paper.

3. I find that the default is a little too perspective though, so right-click it and select “Format Picture”.

4. Use the 3-D Rotation menu to adjust the perspective and Y axis.

You can get pretty crazy with Office picture formatting.

Why yes sir, we do have plastic duck eight-ball clipart. Just the one today?

See you all in a few weeks,

Ned “please don’t audit me, I was kidding” Pyle
Version history
Last update:
‎Apr 04 2019 04:34 PM
Updated by: