It was short, it was fun, but sometimes I was too busy to post a new blog.  So, I am moving my attention to a team blog located at blogs.technet.com/b/askpfeplat.

This is a group of Microsoft Premier Field Engineers (PFE) sharing a blog for platforms.  Hence the name “Ask PFE Platforms.”  You will find some great posts there already, and today was my first contribution to the team blog.

So, no more needed to be said here.  Go to the blog already!  “Ask PFE Platforms.”

Thanks,

Doug Gabbard, Microsoft Senior PFE

Scavenging works great on Microsoft Active Directory Integrated DNS.  So why does it get blamed for DNS issues?  The reason is pretty simple and can be summarized with two words: Patience and Misunderstanding.

First let’s understand how it works.  It takes two.  Yes there two configurations to set and they are both needed for the scavenging to be automated. 

• Server Scavenging Must Be Enabled
  • Settings Do not replicate
  • Restart of DNS restarts countdown
• Zone Aging Must Be Enabled
  • Refresh/No Refresh settings replicate
  • Time stamps replicate if aging is enabled

• Server Scavenging
  • Managed on DNS server properties
  • Not replicated to other servers
  • Initiates event log entry (2502)

• Aging Enabled
  • Managed on each zone’s properties
  • Refresh/No Refresh
  • Settings replicate
  • Time stamps replicate

So let’s talk about those 2 settings: since it takes two..

Scavenging Setting

Server scavenging should be looked at as an event in time that occurs every X days.  Which 7 is the default value.  So if a server is configured to scavenge records it will do so every 7 days like a scheduled task.  A problem with this, is that the time restarts when the DNS server or service restarts.  Therefore, if you reboot or restart the DNS service on your scavenging server, it will be 7 days out before it scavenges.

If aging is not setup, the scavenging event will still occur, but have nothing to do.  For the scavenging to actually delete records it takes two and thus far I am only talking about the scavenging setting on the server.  Remember, this does not replicate, meaning if you retire the scavenging server and do not select another, you are no longer scavenging records if this was you only scavenging server.

Moving on the the 2nd of “it takes two.”

Aging

Aging is independent of scavenging.  You do not have to setup scavenging for the aging to work.  In-fact, I would recommend setting up aging before scavenging so you can see what a scavenging server is going to see.

By default aging is disabled and with aging disabled, time stamps on the DNS records are not replicated.  This should explain why Scavenging has nothing to do if aging is disabled.  If aging is disabled but scavenging is enabled, the scavenging event will occur and simply skip each zone and log event 2501 in the DNS log stating it did its job and did not delete any records.  Enabling aging opens the gates of replication for the DNS records, so that all DNS servers hosting the zone have updated time stamps and are candidates to be a scavenging server.

Keeping with the “It takes two” theme - Aging has two key settings:  NO refresh and Refresh Intervals.

When you turn on aging DNS record timestamps begin to replicate.  The NO refresh interval is there to dampen/reduce replication traffic.  There is no need to keep accepting refreshes if the IP is the same and some user or service is refreshing the record.  Default is 7 days.  This means once a record is created/refreshed it will not accept a refresh to the time stamp for 7 days.

The refresh interval is the time DNS will accept a refresh to the time stamp.  And actually the interval is open ended and will accept a refresh on any day past the NO refresh as long as it exists in DNS.  The interval is there to provide a calculation on what is stale.  The scavenging event will delete any record that is older than NO refresh + Refresh.  By default that would be older than 14 days.

Great stuff.  But you say you have everything setup correctly but you see records as old as 20 days and some real close to 21.  What gives?  What happens is this.  If a record was just under 14 days old when scavenging occurred and the next scheduled scavenging event is 7 days out, then that would put that record at almost 21 days old when it would actually get deleted.  This graphic below will depict this much better than my words and you can see it gets deleted on day 15:

One last discussion.  Common mistakes with setting up scavenging.

1. Refresh interval too short – results in lost DNS records because clients have insufficient time to refresh their records
2. Not patient.  When I work with engineers that are tasked with setting up scavenging.  For some reason they feel the need to speed up the 7 day/ 7 day /7 day settings.  Just remember if it hasn’t been setup for years, why today, does it have to be done fast pace all of a sudden.
3. Aging is zone by zone by zone and it replicates with its partners.  You must setup aging on each individual zone if you want that zone to be scavenged.  Don’t forget the reverse lookup zones.
4. Make sure the DNS servers accept dynamic updates
5. Make sure the clients are configured for automatic updates.
6. TEST IN LAB before making any production changes.
7. BACKUP your DNS prior to making any changes.
8. Monitor for event ID 2501 – make sure it is happening and deleting records.

To close out my fun with it takes two here is a summary.

• Scavenging still occurs with aging disabled on all zones, but will just skip every zone and log that it succeeded.
• Aging without scavenging only increases replication traffic.  Aging will never delete a record by itself.
• With both disabled: well I think you know that answer.

I am interested what you read or sources you use to keep up with technical information in your field.  Working for Microsoft and focusing on platform technology, I obviously lean toward Microsoft information.  I seem to learn the most from www.blogs.technet.com/askds.   This blog is all about Directory Services and provides great insight and practical application of many concepts.  Sometime there is humor injected in the posts which makes the reading more human.  I have frequently used askds on site with customers and when trying to learn a new concept in my labs.

Non-Microsoft resources that I use A LOT are on www.twit.tv.  There are many podcasts available and I am sure you will find one or more that fits your niche.  I listen to two of them regularly (seldom miss).  First is Security Now hosted by Leo Laporte with Steve Gibson from Gibson Research on www.grc.com.   Through this podcast I keep up to date on the latest security vulnerabilities and what industry is doing about them.  He will talk about anything that is cool in security as well what’s not cool in security.  He also talks about his harddrive recovery utility: SpinRite.  So you may know of him through that tool.   His last podcast covered risks with WPS (a new easy security setup) protocol for wireless routers.  Well worth listening to as are all his podcasts if you are in to security.

The second podcast I frequent is Windows Weekly.  This one is also hosted by Leo Laporte with Paul Thurrott (author of Super Site for Windows - www.winsupersite.com ) and Mary Joe Foley (blog on zdnet - www.zdnet.com/blog/microsoft ).  This podcast has great updates on Windows 7 and Windows Phone 7.  They are also dabbling in Windows 8, but with not much released they mostly speculate where they are unsure.

Other resources I use:

www.wservernews.com – great for insights and some non-technical links to cool videos.

www.techrepublic.com.  This was one of my main study resources in the early days of my MCSE certifications.

When all else fails, I use www.bing.com. 

What do you use?  Post your favorites in the comments below.  Try to keep it one or two of your favorites and tell us why you like it.  I am sure we will learn from each other.

Setup

There are a couple of ways to collect a trace during logon from a client. One way is to hook up a hub to the client and use another client connected to the same hub to capture the traffic.  However, with the help with a SysyInternals tool (PSexec.exe) and NMcap.exe we can collect a trace of a logon just using the client.

We will use PSEXEC to launch NmCap as system, so that when you log off the network trace will continue to run. In the command to launch NmCap we will give it a trigger to stop the trace. Once the trace is started, simply log off and back on. Then use the trigger to stop the trace.  I provide a trigger using ping, but there are others such as “/timeafter 5 min” where the trace will stop by itself.

To set this up perform the following tasks on your client machine.

1. Install Netmon 3.x

2. Download PSexec if you do not have a copy already

3. Open an Explorer window

4. Navigate to the root of the C: drive

5. Create folder with the name C:\LogonTrace

6. Copy PSEXEC.EXE into the folder

7. Create a text file named LogonTrace.cmd

8. Enter the following command in the text file:

psexec -d -s "C:\Program Files\Microsoft Network Monitor 3\nmcap.exe" /network * /capture /file c:\LogonTrace\Logon_Trace.cap /stopwhen /frame Ipv4.DestinationAddress == 1.2.3.4

You are now ready to create the trace

Create a trace during your logon

1. Open a command prompt on client used in the setup above (run as administrator)

2. Navigate to the C:\LogonTrace folder

3. Type LogonTrace.cmd

The trace is now running

4. Log off

5. Log on

6. Open a cmd prompt (run as admain again) and use IPCONFIG to register DNS to force some DNS traffic

if you like, open task manager to see nmcap.exe process is running

7. Type ping 1.2.3.4

This should stop the trace – look at taskmanager again to verify

Now you should have a trace with logon traffic for your user account.  Review the trace to find specific information related to locating domain controllers, registering DNS, locating SYSVOL for GPOs and logon scripts, etc.

Here are some useful filters you may find helpful.

To filter on traffic sent to and received from your client use the following filter:

Ipv4.address == <IP Address of client>

Here are two different filters for Kerberos traffic. Try them both to see if you get a difference.

Tcp.port==88 || udp.port==88

Or you could use a very simple filter

keberosV5

You can use the following for SMB when looking for SYSVOL connections:

Tcp.port==445

or you can use the protocol again

smb || smb2

You should experiment with other protocol and port filters to find other traffic as well.  The few filters above are just some examples to get you started.  Enjoy

With the growth of PowerShell many of us are finding we are using a command window of one kind or another for a DOS command or a PowerShell command.  So if I can be so bold, my first recommendation is to just use the PowerShell window and not open a CMD window.  You can do all your favorite DOS commands and PowerShell commands in PowerShell.  If you haven’t made your New Year’s resolution – this is it, start launching PowerShell.

Here is my simple tip:

F7

That’s it. F7.  Don’t feel bad if you forgot or was not aware using F7 in a command window.  Here is what it does.  Once you have typed a few commands or many commands you can use F7 to see a list of the commands you have typed and can easily use your arrow keys to navigate.  Once you locate the command you want you have a choice on how it behaves.   Hit enter and the highlighted command executes.  If you want to edit the command prior to executing, then hit the left or right arrow after highlighting the command.

The other method is to not use F7 and use the up and down arrow keys to find your command.  I use both methods.  In addition, since I have exposed F7 there are other function keys as well you may be interested in.  But I do not use them:

Here they all are:

F2 – “Enter char to copy to.”  This allows you to tell it to go the nth character of the previous command.  Maybe you count as you type, but I don’t.  This may be useful sometime.  However, I cannot think of a time.

F3 – brings the previous command back (same as hitting the up arrow once, but cannot keep going up).

F7 - brings up a window with choices.

So I know you are going to do it, so stop reading this and open PowerShell and type a few commands then hit F7.

I was on site (some time ago) reviewing data for an ADRAP (Active Directory Risk Assessment Program).  One of the issues identified was an event log entry.  The eventID is not significant for this discussion, other than I was looking for an event.  The ADRAP tool looks 5 days back by default and I wanted to look for the total number of occurrences on all the domain controllers and not be restricted to 5 days.

I could have easily modified the settings on the ADRAP tool to look further back in time, however I was interested in only a single event ID.  So I broke out eventComb.  I then searched for the event looking many months in the past and to my surprise eventComb did not find a single occurrence of the event I was trying to find.

I had to have done something wrong: typo on the events, wrong date range, or some other user error.  After some head scratching I looked back at the ADRAP tool event and found the event I was looking for occurred 5 months in the FUTURE.  Argh!

My focus changed.  I was now more concerned to find which domain controllers had future events – which would indicate a time shift.  Moving time forward and back or vice versa can be detrimental to say the least to the entire forest.

I could have used eventComb again, but being a novice at PowerShell I decided to try my hand at PowerShell to find events on all domain controllers regardless of the event ID that occurred in the future.

A simple command in powershell can find this for you:

get-eventlog –log system –computer dc1.contoso.com –after 1/5/2012

This is great if you only have 1 DC and only want to look in the system log.  Or have idle time on your hands and can keep running the same command manually for each log on each DC.  Not practical.  So I have polished that command into a script and have it here for you.   It is not domain specific, but only looks in the system, application, and security logs.  I did not choose the NTFRS log because it is not very active and not a likely location to find a future event.  Likewise, I did not include the DNS log because you may not have DNS on all domain controllers.  However, the three event logs should provide a hit if there is a future event.

Restricted Groups

Restricted Groups! Argh! We have all done this at least once: Setup a restricted group thinking it would add to the local administrators group of the local machines for the users only to find that the policy removes the existing members and replaces them with the users defined by the policy. This is great if every machine has same set of requirements for who should be local administrators. This is seldom true.

Wouldn't it be nice for the user to be able to call the help desk to request permission to be local admin of their machine and with proper approval have the help desk place that user in the local administrators without adding them to every machine (restricted group policy) and without having to modify a GPO AND without manually adding them to the local administrators group? Wouldn't it be nice to not have run on sentences?

So good news for you.  There is a way to manage the local administrator groups on local machines with GPO Preferences. What is really COOL here is that you do not need a Windows 2008 or a 2008 R2 domain controller. YES, you can do this in a Windows 2003 forest/domain with no Windows 2008 or 2008 R2 domain controllers. Ah, but I have a mix of XP and Windows 7 clients, you say. This works from XP SP2 (not supported) and up.

It takes a few steps to setup, but it gives granular control to give a specific user, users, or groups administrative rights  to a specific computer. The following is the framework needed to accomplish this task.

Framework needed:

1. Windows 2003 or greater forest. Really! Yes, really.

1. GPO Policy needs to be managed from Windows 7/2008 R2 or Vista/2008 (Does not have to be a domain controller). Once you move to Windows 7/2008 R2, do not use Vista or 2008 or 2003/XP to manage policies.
2. You will need a group name for each machine account that you want to manage.
   1. For example a machine name CIN1234W7 would also have a global group or domain local group named "CIN1234W7 - Admins." Or something of that nature.
   1. The cool part here is if the group does not exist, the machine will not apply the policy. No harm done.
   2. The Help Desk can use this group add a user for local administrative access. And can likewise remove the user from the group when local administrative access is no longer needed.

1. One GPO applied on an OU above the machine accounts

1. For Windows XP, the Client Side Extensions for preferences needs to be applied. This will work for XP SP2 and above.
   1. Client side extension: www.microsoft.com/download/en/details.aspx?displaylang=en&id=3628
   1. Look here for MS Support Policies: support.microsoft.com/lifecycle

Here are three GPO choices to manage local administrative access:

1. Use restricted groups - old method not granular and applies to many machines
   1. This is the old school method and is more like a authoritarian rule that says this is what everybody gets. You could make this a little granular by creating multiple GPOs linked to each OU but any changes to group membership would require a GPO change that affects all machines under this policy.

1. Use preferences with a form of restricted groups (most control)
   1. May not scale to larger environments
   2. However, not needed to be made a global policy across all machines
   3. This clears current membership and populates it as restricted groups would do.
   4. Allows Help Desk to add to the local administrators with a simple group membership change

1. Use only one preference setting (only adds to existing groups)
   1. Similar to the 2nd choice, but this only adds to the existing members and does not remove any members. So if the build process is adding groups that need local administrative access (and those groups will never change - ha ha), then this would work.
   2. If the groups change you could always use choice 1 or 2 to clean them out.

So with all that up front, let's sort of start over and redefine the problem and solution.

Problem:

Provide consistent set of support engineers local administrative rights and also on request, temporarily (or long term), grant specific user or groups local administrative rights. Without impacting all machines under the policy.

Solution:

Group Policy Preferences. Computer Configuration/Control Panel Settings/Local Users and Groups and add two new settings.

This policy above is shown completed after the two steps below.

Step 1: Define standard local admins that should be on the workstations.  This is the same as the restricted group you are familiar with.  To get the dialog box below create a new policy and navigate to the “Local Users and Groups” under the Preferences settings for Computer Configuration.  Then in the window to the right, Right Click and choose New: Local Group and complete as shown below. Take note of the two check boxes, we will be doing something different for the next step.

This list of Members are the members that should always have local admin rights.  Note both Delete All check boxes are checked.  This makes it work like the restricted groups that you are used to.  So to add the flexibility of adding a single user to the local admin you need to add the second group which is the dialog box below.

Step 2:  Add a specific domain group to the local admins.

Same steps as above with in the same policy add another group. Note the "Delete all…" check boxes are not checked.

This above MEMBER is “%DomainName%\%ComputerName - Administrators”   Without the quotes. This is a global group (could be domain local) but that group does not need to exist unless you want to grant additional users admin rights.  If it does not exist then the policy will ignore it.  If the group exists then those in the group are added to the local admins.  Using Environment Variables %ComputerName% gives you the granular control you need. Want a list of available environment variables? After clicking the Add button press F3 to see a list of available environment variables.

It is important the order of adding the two "local group" settings. If you reverse them, then the result will only be the members of the setting that has the "delete all…" boxes checked since it would be the last one processed.

Once this is setup let’s say a user named Joe User needs "Administrative" access to his local computer named LTCincy001.  The steps to grant him admin rights are to create a group in AD named “LTCcncy001 - Administrators” and put Joe User in it.  That’s it.  A GPO refresh will add him to the local administrators without impacting the other computer local administrator group memberships.  GPupdate /force will do the trick.

So you could pre-create all, some, or none of these groups with no members and delegate permissions to manage the group membership if you want to control it that way. There are many possibilities.

Hopefully, this gets some of your creative minds thinking and make you want to dive into group policy preferences a little deeper.

<theEnd>

It’s about time.  After much promising and procrastinating and so on and so on, I am finally here.  This is my first real blog post.  Introductions don’t count. 

This blog walks through some basic steps to setup a lab from a production network.  I am sure you can modify it to fit your needs.  The main goal to create a lab that closely resembles a production environment without breaking any rules.  We will be creating a lab from the ground up that hopefully looks like your production environment.   Here are some DO NOTS before we get into the steps of creating a lab:

DO NOTS

1. DO NOT create a snapshot of domain controller and place in an isolated network – someone will UN isolated the lab one day and your mileage will vary WHEN (not if) that happens.
2. DO NOT take a physical domain controller from production domain to an isolated network to build a lab – It is feasible that a lab network that has had all the production domain controllers’ metadata removed from the lab can then successfully remove the domain controllers from the production environment also WHEN they two environments are UN isolated.
3. DO NOT use backups of a production environment to create a lab – the lab forest will have the same forest GUID and if connect to production will cause issues.
4. DO NOT use production domain controllers for testing – no matter how much you promise the testing will not replicate to the other domain controllers and that the domain controllers used for testing will be formatted and all metadata removed.
5. DO NOT give the lab forest name the same as the production forest.  Using the same name will confuse even the best engineer and can lead to changes being made to the wrong environment.
6. DO NOT not have a lab.  Is that grammatically correct – NOT not?

So then the obvious question is how do I get a lab that closely mirrors or resembles my production without putting my production environment at risk.   Glad you asked.  On with one possible solution:

The discussion below provide some hints on setting up a virtual environment by exporting data from production to the test lab.  This uses a Windows 2003 forest to conveniently walk you right in to a lab at the end.  So this is a two for one post.  One – setting up a lab to use for testing and Two – a lab to convert FRS to DFSR. 

One last comment, or one more DO NOT to add to the list above.  DO NOT take my labs straight to a production environment.  I cannot envision all the possible scenarios and roadblock you will face in your production environment.  Rather, use these labs to get a better understanding how things work in directory services.  My future labs will be a much shorter post than this one and will be making assumptions that you can do most of the steps without detailed step by step instructions.  When in doubt use bing.com to do a little research and if you feel the need to share, by all means leave comments.

Enjoy

Getting Started - Set up a Virtual Host

Suggestions to make life in your lab easier:

For Windows 2003 machines

• Install support tools, resource kit tools, GPMC, and any other tools you might need. (i.e. Netmon3.x, Pstools etc.)
• Load i386 folder on the image or create an ISO of the OS.

For all OSes

• Create ISOs for each operating system.
• Create an ISO with all your favorite tools and files.
• You can find utilities that can convert a folder to an ISO. This method is very useful in a virtual environment. You can search with Bing to find utilities that do this nicely.
• Setup multiple VLANs in the lab to simulate sites better.
• Work with the network team so that the router does not allow DHCP requests to pass through. This way you can test other services such as WDS, DHCP, MDT, etc.
• Setup change control for the lab
• Use the lab for training

Build a Windows 2003 Forest to upgrade to 2008/R2

• Fully patch server and take a snapshot (before promoting to DC)
• Configure the DC to point to itself for DNS
• Raise FFL to 2003 if not there already
• Verify DNS is stored in the DomainDNSzones (application partition)
• Verify DC is a global catalog server
• Run ADRPEP32 /Forestprep and ADPREP32 /DomainPrep to prepare the forest for Windows 2008 R2. Use the 2008 R2 CD to run \support\adprep\adprep32.exe

Add a Windows 2008 R2 domain controller

• Add DNS and GC function during the DCpromo process
• Transfer all the FSMO roles to the 2008 R2 DC
• Configure DNS to point to itself and the IP address of the second DC as a secondary

Add a second Windows 2008 R2 domain controller

• Add DNS and GC function during the DCpromo process
• Configure DNS to point to itself and the IP address of the First 2008 R2 DC as a secondary
• DCPromo (Demote) the Windows 2003 server.

Setup Sites and Services

• Create new site - Spoke1
• Rename DefaultFirstSite to Hub
• Rename DefaultSiteLink to Hub-Spoke1
• Set interval on the site link to 15 minutes
• Enable change notification on the site link: Use ADSIedit.msc. Find the site link in the configuration container and edit the properties of the site link. Find the "options" attribute and set it to 1.
• Move one of the DCs to the spoke site.
• Add subnets with a 32 bit subnet masks for the DCs in the appropriate site

Exporting data from Production (manually from command line)

• Use GPMC scripts to export the production environment to an XML file
• Create a folder to export to:

In my steps  below I am using the following folder on a thumb drive.   e:\Lab\GPOBackups

Cscript CreateXMLfromEnvironment.wsf e:\lab\prod.xml /domain:contoso.com /DC:<DCNAME> /templatepath:e:\lab\gpobakups /includeusers

Exporting the data from production (Using a script)

• Create a cmd file named “ExportForLab.cmd” with following commands.

<StartCopyHere>

REM Use desired drive letter
E:
CD\
REM Delete folder if it exists
RD LAB
REM Create folders for GPMC scripts to use
MD LAB
CD LAB
MD GPOBackups
REM Change to the folder where GPMC scripts are stored
C:
“CD\Program files\Microsoft GPMC Scripts”
Cscript CreateXMLfromEnvironment.wsf e:\lab\prod.xml /domain:contoso.com /DC:<DCNAME> /templatepath:e:\lab\gpobakups /includeusers

<EndCopyHere>

Move data to Lab

Warning: Do not import data in to the production environment.  Verify when running the “Import” script or command that you are working in the lab environment.

• Copy the folder structure from the production environment to the lab environment
• ON THE LAB ENVIRONMENT:  Use GPMC scripts to import the environment from the XML file to the lab. Using the /PasswordForUsers:Passw0rd1 means ALL users will have that password. It will not reset passwords if it has conflicts.  You can do this by typing the command every time, or using a script.

Importing the data to the lab (manually on command line)

Cscript CreateEnvronmentFromXML /xml:e:\lab\prod.xml /domain:contoso-lab.com /dc:<DCNAME> /createusersenabled /PasswordForUsers:Passw0rd1

Importing the data to the lab (Using a script)

Create a cmd file named “ImportForLab.cmd” with the following commands

<StartCopyHere>

REM Change to the folder where GPMC scripts are stored
C:
“CD\Program files\Microsoft GPMC Scripts”
Cscript CreateEnvronmentFromXML /xml:e:\lab\prod.xml /domain:contoso-lab.com /dc:<DCNAME> /createusersenabled /PasswordForUsers:Passw0rd1

<EndCopyHere>

Basic lab build is complete and you are ready to use for testing and training as needed. So let's start with a basic FRS to DFSR migration

FRS to DFSR

The first test with your new lab if you choose to do so is to migrate SYSVOL replication from FRS to DFSR.  Please review the link to build a more thorough process for testing and roll out to production.  Below are basic requirements and a short list of steps that you will be doing to migrate SYSVOL replication.   With all labs and test – do this in a lab not production.

technet.microsoft.com/en-us/library/dd640019(WS.10).aspx

Follow the above document and steps recommended. The steps below are the short list of commands you will use to migrate from FRS to DFSR. The steps below are simple and in a lab environment will happen quickly. However in a production environment with many DCs and more complex replication topology will take considerably longer to migrate.

• Build a 2003 forest with one or two domain controllers
• Use ADprep to prepare the forest for Windows 2008 or 2008 R2
• Upgrade the DCs to 2008 or add two new 2008 or 2008 R2 DCs
• Remove/demote the 2003 DCs if not upgraded
• Raise domain functional level to 2008 or 2008 R2
• Verify SYSVOL is replicating
• Verify DFSR is running on all DCs and AD is replicating
• Create a text file with all the domain controllers in the domain delimited with line feeds and name the text file “dclist.txt”. Then run the following commands and review the output. If you create a batch file for the commands below replace the single percentage signs with two percentage signs (%%a)

For /f %a in (dclist.txt) do sc \\%a query dfsr >>%a_health.txt

For /f %a in (dclist.txt) do Repadmin /replsummary %a >>%a_health.txt

For /f %a in (dclist.txt) do repadmin /showrepl %a >>%a_health.txt

Review each DC_health.txt for errors.

Migrate FRS with DFSRmig.exe

Dfsrmig /getmigrationstate (reports status of the migration – make sure all DCs have completed the current state before moving to the next state.

Dfsrmig /setglobalstate 1 (Sets to prepared state)

Dfsrmig /setglobalstate 2 (Sets to redirected state)

Dfsrmig /setglobalstate 3 (Sets to eliminated state)

<the End – dougga>

Who am I and what do I want to do with my blog.

First, my name is Doug Gabbard and I am a Senior Premier Field Engineer working at Microsoft focusing on directory services.  I been working in the field with our customers seeing both small and very large enterprise environments.   I Enjoy working with customer environments (big and small) and appreciate the connections I get to make with talented engineers I meet on a weekly basis.

I have been toying with posting a blog for some time and today is the day.  There are many blogs, so why another one.  Couple of reasons.  I have made many connections to engineers at various customers and often we reproduce how something works or create a lab to troubleshoot an issue - I want to share some of that with you (don't worry - I won't be putting your names in any of my posts for obvious reasons).  Another reason is I love to learn and it is through "doing it" when I learn the most.

Since I am about "doing it" to learn, my blog post will be mainly focused on labs to reproduce an issue or to understand the inner workings of some aspect of directory services.  Many classes we attend have labs that instruct us how to complete the lab.  However, those labs typically start with "click start, all programs, administrative tools, ……"  So, the labs I am going to post are going to assume you know how to do basic tasks.  If for example the lab requires RSAT tools on a Windows 7 client, you will see a step that states "install RSAT on the Windows 7 client."   If you don't know how to perform the step you can search on www.bing.com to find out how.

I will struggle with the formatting of how I share the labs, but it will improve with comments from you.  You will find that my grammar will falter at times, please be kind.  My goal is to publish useful labs.

In the next week or two I will publish my first lab blog.  The lab will be how to create a lab environment from a production environment running Windows 2003 to prepare for an upgrade to Windows 2008 or Windows 2008R2.  This will give you a lab that you can then use for other testing and for future labs I post.  I will never recommend that you practice my labs in your production environment.  Test Test Test!