Should I use .local as part of the domain name? No, here are some info about it

Hi,

I've talked to many customers about using .local in the domain name (example: mydomain.local). I've always stated that they should not and some of the reasons are:

----snip----
From: http://en.wikipedia.org/wiki/.local

Multicast DNS standard

Internet Engineering Task Force (IETF) standards-track RFC 6762, which has been approved and was officially published on February 20, 2013, essentially reserves the use of .local as a pseudo-TLD for link-local hostnames that can be resolved via the Multicast DNS name resolution protocol. Page 5 of that publication states:

...this document allows any computer user to elect to give their computers link-local Multicast DNS host names of the form: "single-dns-label.local.". For example, a laptop computer may answer to the name "MyComputer.local."...

This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addresses in the FE80::/10 prefix, which are link-local and meaningful only on the link where they originate.

Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB)  

...Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion. Implementers choosing to do this should be aware of the potential for user confusion when a given name can produce different results depending on external network conditions (such as, but not limited to, which name lookup mechanism responds faster).

Name resolution issues may arise if multicast DNS software is used in conjunction with a network that implements the local top-level DNS domain.

MS Recommendations

The connection of Macintosh and Linux computers and/or zeroconf peripherals to Windows networks can be problematic if those networks include name servers that use .local as a search domain for internal devices.

At one time, Microsoft at least suggested the use of .local as a pseudo-TLD for small private networks with internal DNS servers, via documents that (as of this writing) are still accessible. For example, support article 296250 included the following option:

Make the name a private domain name that is used for name resolution on the internal Small Business Server network. This name is usually configured with the first-level domain of .local. At the present time, the .local domain name is not registered on the Internet.

However, more recent articles have cautioned or advised against such use of the .local TLD.

Support article 300684 listed contoso.local as an example of a "best-practice Active Directory domain name", but then added:

We recommend that you register DNS names for the top-most internal and external DNS namespaces with an Internet registrar. which would of course preclude using that or any other domain ending with .local.

Technet article 708159 suggested .local for the exact opposite reason:

Using the .local label for the full DNS name for the internal domain is a more secure configuration because the .local label is not registered for use on the Internet. This separates your internal domain from your public Internet domain name.

but later recommended against it:

If you have Macintosh client computers that are running the Macintosh OS X version 10.2 operating system or later, ... it is recommended that you do not use the .local label for the full DNS name of your internal domain. If you have Macintosh client computers that are running the Macintosh OS X version 10.3 operating system or later, ... it is recommended that you do not use the .local label for the full DNS name of your internal domain. If you must use the .local label, then you must also configure settings on the Macintosh computers so they can discover other computers on the network. For more information about how to configure client computers running Macintosh OS X version 10.3 or later, see "Connecting Macintosh Computers to a Windows Small Business Server 2003 Network" on the Microsoft Web site.

Technet article 726016[5] cautioned against using .local:

...we do not recommend using unregistered suffixes, such as .local.

Global .local DNS queries

.local is an officially reserved Special-Use Domain Name and such host names will never be resolvable by the global Domain Name System

 References

1.Cheshire, Stuart, and Krochmal, Marc. "RFC 6762: Multicast DNS". Internet Engineering Task Force.

2."Domain Name System name recommendations for Small Business Server 2000 and Windows Small Business Server 2003". support.microsoft.com.
3."Information about configuring Active Directory domains by using single-label DNS names". support.microsoft.com.
4."Internal Domain Information (OEM)". technet.microsoft.com.

5."Selecting the Forest Root Domain". technet.microsoft.com.

6."Special-Use Domain Names".

7.George Kirikos. "Most Popular Invalid TLDs Should Be Reserved". Circle ID. Archived from the original on 21 June 2009. Retrieved 2013-04-12.
8."Most Popular TLDs Queried". root-servers.org. Archived from the original on 2009-09-16.
----snip----

More info:

Active Directory Domain Naming Considerations:
http://social.technet.microsoft.com/wiki/contents/articles/17974.active-directory-domain-naming-considerations.aspx

I will post more about this when time permits.

Best regards,
/Jimmy

Should I use Rendom.exe?

Well, it all comes down to your environment and how it can handle down-time. Personally I would migrate if possible due to the complexity of the domain rename process.
What you need to understand is that the domain rename process is complex and in some ways "uncontrolled". Meaning that if you start it, it will try to finish or fail.

Things to understand:
- Headless Management: Rendom will not use AD Repl, each DC will be contacted individually.
- Forest will be "offline" during the process: The time is proportional to the number of DCs.
- DC is either successful or must be removed from the forest.
- Member computers must be rebooted twise after all DCs are updated, note that legacy OS needs to unjoin/join the domain.
- DNS host names are not automatically changed during rendom: Primary DNS suffix of the DC will not mathc the new domain DNS name. Requires additional steps after rendom.
- DNS suffix on member computers will not match for a period of time: Time it takes is proportional to the number of machines in the domain and if it is auto updated or not.
- Runs from a separate computer
- CLI interface
- Each DC is changed independently
- Step-by-step, steps must succeed on every DC or it stops
- Steps are idempotent

3 DC states:
- Initial
- Prepared
- Final (success or fail)

Note that Prepared to Final can only be accomplished if every DC in the forest has reached the required state!

Overview of the steps:
- Manually specify the new forest structure
- Generate instructions encoded as script
- Transfer the script to each DC
- Verify the script on every DC to see if it is ready to execute the instructions
- Execute instructions on each DC (forest offline during this step)
- Fix-up Policy metadata
- Clean-up metadata written to the directory

Remember that this is just a basic overview of how it works, you must test, test again and test again in a lab before trying it in production!

The LastLogonTimeStamp Attribute – What it was designed for and how it works

I came across an excellent explanation of the LastLogonTimeStamp attribute and how it actually works:
http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx

If you ever had a question about it, I bet you'll find the answer there.

What is new in Windows 8.1

Here you can read about Windows 8.1: http://technet.microsoft.com/en-us/windows/dn140266. 

NON-LVR groupmembers - how to find them - Step 4.

Step 3 in my blog (http://www.jimmytheswede.blogspot.se/2013/06/non-lvr-groupmembers-how-to-find-them.html) will create a separate file for each group (DN is the filename of the group). Within those files you need to search for the string LEGACY, so what I did in step 4 was to search the files for the string LEGACY and then copy the files into a separate folder.

Note that my folder containing the files is "c:\temp\searchFiles" and I copied the files that contained the string "LEGACY" to the folder "c:\temp\searchResult".

In PowerShell:
get-childitem c:\temp\searchFiles | select-string LEGACY -List |%{copy-item -path $_.path -destination 'c:\temp\searchResult'}

Now I have all files (named as the group's DN) in a separate folder that contains LEGACY members, I then create a list of the filenames as input when I change them (http://www.jimmytheswede.blogspot.se/2013/06/non-lvr-groupmembers-how-to-change-them.html).

TechEd North America Sessions

The session recordings for TechEd  2013 are now available - http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013#fbid=S8kTtlJUJv2

NON-LVR groupmembers - how to change them

After I had removed the groups I didn't want to refresh the group membership in, I ended up with a textfile called refresh.txt as input file.

I ended up using this command in a command prompt to re-add the users in the groups from this file.

for /F "delims=" %f in (refresh.txt) do dsget group %f /members | dsmod group %f /chmbr

Things you must take into consideration is that if you do this on many groups with many members, it will start a lot of replication. So, you might want to split the list into multiple smaller lists to not affect the network too much.

NON-LVR groupmembers - how to find them

Today I was trying to find out which group members that still was LEGACY, meaning not using LVR. I was definately not going to manually look at the groups metadata since it was about 7000+ groups. So this is how I did it form the command prompt:

[the domain name is: demo.net and DC name is DC1 in this example, you need to replace that with your domain and DC]

1. Create a list of all groups in the domain:

Dsquery group dc=demo,dc=net /limit 0 > allGroups.txt

2. Remove all built-in groups and groups that are created by default during a fresh installation since I didn't want to "touch" them.

3. Get objMeta of all groups in the text file:

For /f “delims=” %f in (groups.txt) do repadmin /showobjmeta DC1 %f > metadata\%f

(metadata is the folder where I saved the output files to)

4. Now the only thing left is to search the files created in the metadata folder for LEGACY. And you will have a list of which groups contains non-LVR memberships.

When I have my complete list I will then remove/add the members to be able to utilize LVR. I haven't decided how I will do that yet, but most likely dsget group | dsmod group but I will post that after I've done it.

Evaluate group membership - Address Token Limitations

You can use this to evaluate issues with token sizes, it is especially good in environments that contain complex group structures.

In the below example, my domain is vfroot.prv and my DC name is SDF. In the below example I evaluated a group, but you can evaluate users as well.

To do this you will use the Ntdsutil command:
ntdsutil
ntdsutil: group membership evaluation
group membership evaluation: set account dc SDF
group membership evaluation: set global catalog SDF
group membership evaluation: set resource dc SDF
group membership evaluation: run vfroot.prv grouptest

This will give you output to a file called tab-separated-value (.tsv) file,  that contains the following information:

-SID in Token: Security Identifier that is part of the token.
-SID Type: The type of SID that is being added. The SID can be either the Primary SID or a SID from the sIDHistory attribute.
-SID History Count: The number of SIDs in the sIDHistory attribute for the principal represented by this SID. For a row represented by a sIDHistory SID, the value is zero.
-Distinguished Name: The Distinguished Name (DN) of the entry.
-SamAccountName: The samAccountName attribute for the SID.
-DC Queried: The domain controller (DC) that provided this SID for addition to the list of tokens.
-Group Owner: The samAccountName of the owner of the group. If the SID pertains to an object other than a group, this field contains "N/A."
-Group Owner SID: The SID of the group's owner. If the SID pertains to an object other than a group, this field contains "N/A."
-WhenCreated (UTC): The date and time when the group was created. If the SID pertains to an object other than a group, this field contains "N/A."
-WhenChanged (UTC): The last date and time when any attribute of the group was changed.
-Member WhenChanged (UTC): The last date and time when the membership attribute of the group was changed.
-GroupType WhenChanged (UTC): The last date and time when the GroupType attribute of the group was changed.
-One Level MemberOf Count: The number of groups which this entry is directly a member of.
-Total MemberOf Count: The number of groups which this entry is both directly a member of and recursively a member of.
-Group Type: The type of group that this entry represents. Some examples are: User, Domain Local Security Group, and Well Known Computers.
-Depth From User: The number of transitive links between the group in question and the user. If the user Joe was a member of Group1 which is a member of Group2 which is a member of Group3, then the depth from user Joe to Group3 would be 3. If there is more than one path from the user to Group3 then the shortest path is chosen.
-Closest Parent OU: The closest organizational unit that the entry is a member of.

For more information, please see: http://www.microsoft.com/en-us/download/details.aspx?id=13749