Start here

This folder is waiting for Initial Replication to complete

Hi All,

Just wanted to share a recent experience in resolving replication issue with some folders between DFSR File server Members.

Out of multiple folders configured in DFSR members few folders stopped replicating between each other. When I looked at the DFSR Diagnostics report, I can

see these folders are in “waiting for initial replication” to complete. This is in this stage for more than couple of months. Initially I thought this would

resolve once the initial replication stage is completed but it never did. So time for some troubleshooting technique to be applied.

Why/When did this happen?
The reason why these folders went to the Initial replciation stage is because I had to recently re-configure them. From that point of time,the replication

never happened between the member servers.

Why users did not raise any concerns?
Thats because these folders are least used. Also as part of namespace they are able to connect to these shared folders and they are able to save the contents

in the respective site DFSR member servers. The replication which happens at the background did not happen and it was noticed by them.

How to fix this?

Get a downtime from users, during Out of Office Hours ( may be via Change control process!)

So, to fix this, we need to know some basics of DFSR.

Whenever there is a change happens for any of the folders configured in DFSR, their respective DC’s should recieve this information and keep it up to date

and replicate this change to other DC’s.

In this case, what would have happened is, before DC get to know about the changes, I made a change in the same folder at other DFSR member server too. So

this was the problem and hence this folder is still in initial replication stage for longer time and this will never complete.

We figured out this could be the issue, so,

Login to the DFSR member server which is configured as secondary or configured for other sites. If you have multiple servers configured then you need to

decide on which server’s data can be secondary.

open the DFSR console in secondary server, under the replication group, locate this problematic folder. Right click and click on disable. Click yes to the

warning message.
Now disable the primary one, it will give you a warning,say yes again.

Now you need to wait for minimum one hour.(in my case). This waiting hour depends on your DC replication interval between the sites. If your replication

interval is 15 minutes between the DC’s then wait for 1 hour. This is to adjust if DC has so much to replicate its own data and may go beyond 15 minutes. The

more you give, more the chances of success.

After one hour, now enable the primary server under replication group for this folder. It will ask you for the path, browse and give the same folder which

was configured earlier.

Again wait for the same time period which you did last time.

After one hour, now enable the secondary server under replication group for this folder. It will ask you for the path. browse and give the same folder which

was configured earlier.

Again wait for one hour and enable the servers one by one if you have more member server sets configured.

Finally wait for some time (more than a hour 😉 or probably next day) and see if the replication is now happening.

If it is replicating, you are awesome! Give me a high five! 🙂

Lesson’s Learnt: One important thing while working with DFSR is to giving enough time window before we make multiple changes at the same time.

Hope this is useful!

 

How to Migrate DFSR Shares from One drive to Other drive

Hi All,

Just wanted to share one of my recent experience with Migrating the Shares from One drive to Other Drive which is configured in DFSR.

Drives are Fastly Filling up in Servers due to users dumping  more and more data in the Shares. In Physical infrastructure, it is possible that you can Extend the drives by adding more space on RAID disks. But there is a limit.

In Virtual Infrastructure, the maximum drive size you can have in ESXi5.0 is 2TB-512 Bytes. You can’t extend beyond this.

Only way to overcome this is to start migrating the shares from one drive to a new drive which has more space or newly configured.

Let’s Jump In…

Disable your AV software on server where you are trying to move the shares

Disable the backups programs if any ( if you use any 3rd party backup tools, inform your backup team to disable the backup policies)

Robocopy your data using a script with the syntax. It will also ensure foldernames with spaces are also move properly since it is included with quotes.

robocopy “\\servername\driveletter$\Folder\shared folder name\”  “\\servername\new driveletter$\Folder\shared folder name\” /sec /e /b /copyall /r:6 /xd dfsrprivate /log:c:\results.txt /tee
Once robocopy completed, verify the file hash. Check this for minimum 5 to 10 different folders and files in structure

On the file server at command prompt

dfsrdiag FileHash /Path:”driveletter:\Folder\Shared Folder name”

It will display results as below.

File Hash: ABCDEF55-ABCDEF12-12EFABCD-32ABCDEF

Operation Succeeded

Again run the same command but for new drive to verify the file hash.

dfsrdiag FileHash /Path:”newdriveletter:\Folder\Shared Folder name”

It will display results as below.

File Hash: ABCDEF55-ABCDEF12-12EFABCD-32ABCDEF

Operation Succeeded

Once all file hashes are matching properly, proceed further. Else, STOP here. Apart from AV and your backup program which you disabled initially,something else is also trying to alter the data which you are trying to move. Find out that. Sometime it could be users too.  Inform your users well in advance that namespace path will not be available when you perform this activity. I always do at weekends usually via a proper change control.

Stop sharing your old folder which is on drive which has less space.

Share your folder which is on drive where data is moved recently.

Confirm all permissions are intact. It would normally because the above robocopy script which was used included the security permissions as well.

Now locate the replicated folder which you would like to change its path from one drive to another drive under replication group

Right click on Folder and click on disable. Wait for complete.

Now right click again and click enable, while enabling it would ask you for the path. Here, change it to the new drive and shared folder ( which you shared on new drive few mins back)

Once done, you will see the path has been changed to new drive.

Confirm namespace is accessible without any issues.

You will see an event under DFS replication as Configuration has been updated.

Now replication for this folder will be picked up when DC has informed DFS server that changes are recieved and replicated to other DFS member.

If you can afford reboot of this file server, you can give it a shot. ( but this is not necessary)

This folder will be placed into initial replication stage for a while (sometimes it takes days as well)

Once DFS detects everything properly this folder will start replicating the contents as before.

In my experience,it took a week for me to replicate the new data between the servers.

Hope this helps everyone!  TEST TEST TEST before you target this on large share. Please let me know if anyone has any queries.. Happy to help.. 🙂

This article helped me in greater extent on completing this activity. Thanks to author Ned Pyle for his detailed explanations on how it works..

 http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx

 

 

 

RODC and it’s Authentication Mechanisms

Hi All,

Just wanted to explain the authentication steps involved in RODC deployments.  🙂

Read only Domain Controllers (RODC) can be deployed in sites where we don’t have a physical security of Domain Controller. Since AD works on multi-master replication, if someone hacks that domain controller and make some changes to ntds.dit and put it back to network again, it will corrupt the entire AD domain.  

In these cases, we can deploy RODC in those sites.

How it secures AD?
All replication to RODC are one way. It means, RODC always recieve only in-bound replication. It doesn’t replicate anything to any other DC’s. No out bound replication.

Points to remember before deploying: -)

We need to Cache both user and computer accounts in RODC, only then authentication will succeed in case of WAN failure

Each and every domain controller (including RODC) has its unique domain KRBTGT account and it’s replicated to each and every Domain Controller in domain
All RODC KRBTGT account is replicated to all RWDC’s in domain
RWDC’s KRBTGT account will not be replicated to any RODC  in domain

To issue a valid kerberos ticket to user/computer , that user/computer kereberos ticket must be signed with its respective domain controller KRBTGT account. If a domain controller recieves a ticket request signed by some other Domain controller’s KRBTGT account, it will request the user/computer to generate a new ticket again so that it can issue a valid ticket.

Click here to view : Sites with RWDC and RODC

Phase 1 : – Computer Authentication
Computer contacts RODC by issuing a KRB_AS_REQ ticket
Since RODC doesn’t have computer account password cached locally, it forwards the request to RWDC
RWDC responds with KRB_AS_REP signed with domain KRBTGT account
Now, RODC again checks with RWDC to confirm if this computer account password can be cached locally? Let’s assume yes and then it stores the computer password

Phase 2 : User Authentication
User contacts RODC by granting a  KRB_AS_REQ ticket
Since RODC doesnt have the user’s password cached locally it forwards the request to RWDC
RWDC responds with KRB_AS_REP signed with domain KRBTGT account
Now, RODC again checks with RWDC to confirm if this user account password can be cached locally? Let’s assume yes and then it stores the user password in local RODC database

Phase 3 : Service Ticket
For user to use his computer he should have Ticket Granting Service (TGS) ticket.
Now Computer generates TGS with user’s KRBTGT and forwards to RODC by issuing a KRB_TGS_REQ
RODC can’t decrypt TGT of user because it is signed with domain KRBTGT account
So, it forwards to RWDC. RWDC responds back with KRB_TGS_REP

Now, RODC rather forwarding this TGS ticket to computer directly ,it makes the user to generate a new KRB_AS_REQ because it doesn’t have to rely on RWDC for authentication next time. Also, remember each and every kerberos ticket should be signed with respective DC’s KRBTGT account.

Now again KRB_AS_REQ is generated for user , since password is already cached, RODC itself responds with KRB_AS_REP with RODC krbtgt account
Now again new TGS ticket is generated with KRB_TGS_REQ with user’s KRBTGT account.
This time RODC able to issue KRB_TGS_REP allows user to access his computer

All 3 Phases will happen for all user and computer accounts when they contact  RODC first time. However during subsequent attempts, KRB_AS_REQ for user and  computer account will be directly responded by RODC because computer and user accounts passwords are locally cached on RODC itself.

It may be a lengthy post as it seems ,but if you go through slowly you would be able to understand clearly.. 🙂

Hope it is clear and useful! 🙂 Comments are always welcome! 🙂

Upgrading a new Domain Controller with Same Old DC Name and IP

Hi All,

A Recent Upgrade Experience : –  )

Scenario: – A site with only one Domain Controller which is running with Older hardware architecture.  You need to upgrade RAM, HDD, need to regularly install updates. Since it is running in old hardware, you are unable to proceed further. So, in this case, you explain the importance of this DC ( being only one at that site ) to your IT head. After running through various meetings finally it is approved and you recive a brand new server. Wow.. Long time wait..

Now, Old DC is already in retiring state, you don’t want to bother it anymore. So what you can do is, promote this new server as DC with same old name and IP.

Adv: – You don’t  have to change any settings at your client side for DNS . You don’t have to inform your apps team who are manually hardcoding this DC for their apps to work. 

Let’s get it started. Below are the procedures on how to achieve it.

Procedures:-

  • Make sure none of the FSMO roles are configured on this DC, if yes, move them to different DC.
  • Demote this DC – Remove DNS as well, if its AD integrated
  • Make sure its completely replicated over entire forest
  •  Check if there are any references about this DC in any other DC’s.  For Ex, confirm none of the DC’s see this DC as replication partner.
  •  Once this is demoted successfully and made as a member server, shutdown the old DC.
  • If demotion was not successful, follow http://support.microsoft.com/kb/216498   and make sure all references are removed as highlighted.
  •  Remove the DNS record which is created for this DC
  • Install OS on Server as same as Old DC and make it available on same Server VLAN.
  •  Now boot up the new server with upgraded H/W on the same subnet which is already on Workgroup.
  • Rename as old DC and set the IP address as old DC and restart the server
  •  Once back online, promote as a new DC and install DNS- AD integrated.
  •  If old server  was a GC (in these cases mostly yes) , make it as  GC as well
  •  Once done, confirm this is replicated over entire forest and functions as normal
  • Confirm other DC’s can see this new DC (with old name) as their replication partners

It is very simple and you all set now.. 🙂 It worked for me..

Note: – If this server was also a DHCP server, you may have to restore the DHCP Database as well.  Refer:- http://technet.microsoft.com/en-us/library/cc736344(v=ws.10).aspx

Hope it is clear and useful.. 🙂

 

DNS Scavenging.. It’s recommended..

                                                                            DNS Scavenging

Once the records are registered by clients in DNS server, if scavenging is not enabled, your dns server may have stale records which are not useful in your environment. Sometimes, this may also lead to a problem that dns server responding with different answers when a dns query is made.

This scavenging process will not be applicable for the resource records which are created manually. TTL value for these records will be zero. These records will not participate in scavenging process.

There are four important paremeters are available to make use of the scavenging.

  • Scavenging interval
  • Aging configuration
  • No-refresh interval
  • Refresh interval

Scavening interval:- This can be viewed by looking at the properties of a dns zone. Click on the scavenging tab and default time limit is 168 hours( 7 days). After enabling this, records which are not updated for 7 days will be automatically deleted.

Aging Configuration: This has to be set as 1 to enable scavenging process. Default value is 0.

No- Refresh Interval :- After a record is updated in the dns server, the record will not recieve any updates after this time period. Default value is 7 days. But if the IP address or hostname changes, that will be updated.

Refresh interval :- After the No-refresh interval set above, a record can wait for time period mentioned here to get an update. Default value is 7 days. For ex, a record is generated and no updates recieved for that record for the first 7 days. Within, the next 7 days, if the record doesn’t get any update, it will considered as STALE. This record in turn will be deleted after 7 days. So totally, ifyou leave the default configuration of 7 days in all the above  parameters, stale dns records will be deleted after 21 days.

Hope it’s clear and useful.. 🙂

Building your first Lab environment and you need to rename your DC now!

Hi all,

When we start learning anything new, we need to learn most of things in practical way. So, we decide to build a lab environment on our own. Thanks to virtualization technology. 🙂

This is what I tried in my environment and when i built my first lab in a laptop using vmware workstation my objective was simple

*** I need a domain environment where i can practice my AD skills such as creating and applying GPO’s,Creating user accounts,troubleshooting replication issues etc.,

So boot up your computer download and install vmware workstation. go with the default options. Using a ISO image install the latest server OS.You’re halfway through it. Now you login and do a dcpromo and make the servers as Domain Controllers. You’re so happy that you’ve installed a Domain Controller Succesfully! Congrats! 🙂

After you restart and see your domain controller name you would be surprised that it came with some different names which you can’t even remember.  😦 Now how do i change my domain controller name? You do a google and you get lot of steps from technet.Still, You think if someone can help you now  it would be better. I had the same experience like you. Below are the steps i tried after careful inspection and documented it for reference.  Below are the things that you need to do.

Renaming a DC is 3 step process. First you add a new name for your DC. Second you make it as a primary name and restart the DC. After the restart, remove the old name.

Here, mohan-395vnrr4w is a computer name given by default and i need to change it as  dc1. So do the following.

Go to your command prompt on DC and run the following commands substitute the new name of your DC whatever you like after the add parameter.

C:\Documents and Settings\mohan>NETDOM COMPUTERNAME mohan-395vnrr4w.INFINITELOOP

.LOCAL /ADD:DC1.INFINITELOOP.LOCAL

Successfully added DC1.INFINITELOOP.LOCAL as an alternate name for the computer.

C:\Documents and Settings\mohan>NETDOM COMPUTERNAME mohan-395vnrr4w.INFINITELOOP

.LOCAL /makeprimary:DC1.INFINITELOOP.LOCAL

Successfully made DC1.INFINITELOOP.LOCAL the primary name for the computer. The computer must be rebooted for this name change to take effect. Until then this computer may not be able to authenticate users and other computers, and may not be authenticated by other computers in

the forest. The specified new name was removed from the list of alternate computer names. The primary computer name will be set to the specified new name after the reboot.

The command completed successfully.

Once the reboot is done you need to run the below command.

C:\Documents and Settings\mohan>NETDOM COMPUTERNAME DC1.INFINITELOOP.LOCAL /REMO

VE mohan-395vnrr4w.INFINITELOOP.LOCAL

Successfully removed mohan-395vnrr4w.INFINITELOOP.LOCAL

as an alternamte name for the computer.

The command completed successfully.

Restart you DC once again and you can see your new name.

Hope this is helpful! 🙂

All About Active Directory! All about my Passion! :)

Hi All,

I would like to thank you for spending your time here to read my Blog!  As you would have guessed already what i’m gonna blog about..  Yeah It’s all about AD!  A technology which makes me wonder everyday…..  The technology which i’m impressed…  🙂

As the Organizations are completely relied on computers for the business solutions, organizing their work and making most out of computers through various software, is all Microsoft about.. I always like to call ’em as MS! 🙂 As most other engineers do…

Okay, My blog posts are mostly on Directory Services a.k.a AD, through the series of articles. I’m gonna explain right from the basics to deeper level.. Most of the articles you would find here are answers / explanations to the doubts/questions which i got during my initial stage of learning AD .

I also work with Virtual Infrastructure hosted on Vmware.  In my View, it saves large amount of money to larger enterprises with their virtualizaton technology. You will find some blog posts about vmware issues/techniques as well.

Hope it is useful to everyone!

Once again thanks for your time! 🙂 All your feedback and comments are welcome!

Cheers,

Mohan R