Considerations for Microsoft DFS (Distibuted File System)

Many people look at DFS as a means to replicate data between servers and different branches.

Some thing to take note of before deciding to implement DFS:

1. You would need enough free space for the staging quota on the drives that contains the replication data. The staging quota is the area on the disk where the files that will be replicated are compressed to before they replicate to the other server. By default your staging qouta is 4GB but generally you will make this bigger.

2. If you have big files (Larger than 4GB) that is part of the data that will be replicated you would need to increase the staging quota. Any files larger than the staging quota won’t be able to replicate. Generally you want to increase the staging quote to as this can decrease the needed replication times.

3. When you setup DFS for the first time it can be very resource intensive on the CPU’s (Initial big replication).

4. DFS can be difficult to manage / troubleshoot if there are problems.

5. Certain firewall’s tend to cause problems when replicating over a WAN. In one scenario we had the situation where the Sonicwall was dropping the TCP connection after a certain period of time so the initial replication could never complete.

6. You can’t create new replication groups of folders that are already within an existing replication group.

7. Backups should not run at the same time as the DFS replication, otherwise it will backup the temporary staging folders. Should your DFS replication be scheduled to run all the time then make sure you remove the staging folders from the backup selection.

8. Users can overwrite eah others work if you are using DFS replication over a WAN to different file servers.

Make sure you run health reports in DFS to ensure your data is replicating correctly before you decommission one DFS server.

Terminal Server high availability – RDS session broker – Server 2008

Things to consider before implementation:

  • You would need to setup Roaming profiles for all TS users. All the local profiles on the current terminal servers would need to be moved to a central network location.
  • All clients that will be connecting to the TS server would need to have RDP version 6.1 or later (Otherwise the client would need to log in twice when they are redirected to another TS server via TS Session Broker – This happens when load balancing kicks in).

You can use the MS technet article for the installation of Session Broker:

http://technet.microsoft.com/en-us/library/cc771419.aspx

Possible problems you might face after implementation:

  • Users keep on being logged in with a temporary profile (This usually only happened on a problematic TS server, not all of them). To resolve this:
    • Delete the registry key that specifies the location of the user’s profile (This will be automatically recreated when the user logs in again).

The location of the registry key: Computer\HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\ProfileList

 

 

JRNL_WRAP_ERROR – Event 13568, Ntfrs – Server 2008

Getting a JRNL_WRAP error in your event logs is never a pretty site. Losing all you policies and scripts that was in your sysvol folder after fixing the JRNL_WRAP is even worst. This happens when you do the below fixes in an environment where you have only one DC. If you have more than one DC you don’t need to worry as the server that you are applying the fix to will pull the sysvol data from one of the other DC’s.

Ok, so there are two ways of fixing a JRNL_ WRAP error in Server 2008 (Remember to make a system state backup before you do this).

 

  1. Follow the instructions that is described in the Server 2008 event viewer – This does an auto restore. Unfortunately this process does not always work, we have had it a couple of times where we sit and wait for this auto restore process to finish but it never happens.

2.   Use the burflags method to do an authoritative or nonauthoritative restore

a. In Command prompt, type ‘net stop ntfrs’.
b. Open the registry (Click start, In the Run box, type regedit and press ENTER).
c. Locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\NtFrs\Parameters\Backup/Restore\Process at Startup
d. In the right pane, double-click BurFlags.
e. In the Edit DWORD Value dialog box, type D2 and then click OK (This does a nonauthoritative restore, Use ‘D4’ for an authoritative restore).
f. Quit Registry Editor, and then switch to the Command Prompt and type ‘net start ntfrs’..

As soon as the FRS service restarts the following happens:
• The BurFlags registry key returns to 0.
• Content in the Sysvol folder are moved to the Pre-existing folder.
• FRS database is rebuilt.
• The server performs an initial join of the replica set from a partner.
• The server performs a full replication of the replica sets.

Obviously  you would like to make sure that you don’t lose your sysvol data (Policies and scripts) – This happens when you run the above fixes in an environment where you only have one DC.

 

So to prevent this do the following:

 

  1. Run a system state backup before you make any changes.
  2. As soon as you apply the auto restore fix (Option 1 on the above fixes), you will see that it creates a ‘Ntfrs_PreExisting’ folder in the sysvol folder. All the policies and scripts that you had will be moved into this folder. Make a backup of these files before they are removed by the system (See below screen shot for details). You won’t be able to copy these files out before they are moved to the Ntfrs_PreExisting folder as the system locks them.
  3. Once the auto restore process completes – Copy the sysvol files that you backed up to the new sysvol folder that will automatically be shares once the process is complete.

 

Should the auto restore process not work, run the burflags fix (Option 2 above) and copy the sysvol files that you backed up to the new sysvol that will be shared after a successful fix.

You will know that the JRNL_WRAP error is fixed if you get the below entry in the event viewer.

 

 

 

 

Extra DNS entry automatically created for server

I came across a problem where I saw that an extra DNS A record kept on being registered in DNS for a new SBS2011 server that I installed. This IP was not assigned to any of my network cards and this entry kept on re-appearing after I deleted it from DNS.

After some digging I found that it was the IP that RRAS was assigning to the server (This server is an AD and RRAS server).

So to resolve this:

  1. Open DNS manager.
  2. Right click on your DNS server and select properties.
  3. Select the Interfaces tab and remove the IP that was assigned to the server by RRAS.

4. Now delete the unwanted DNS entry (Host record) from DNS and this should be resolved.

 

Planning your server upgrades

There are plenty documentation on the Net on the technical side of upgrading your server environment but very little on the actual processes that should be followed, things to consider and what to look out for. So we thought we will give you a brief run down on this. You can download the detailed process document here.

As with most projects you need to focus on the following 4 phases:

  1. Site analysis
  2. Preparation
  3. Execution
  4. Testing and problem solving

 

 

 

 

 

 

1. Site Analysis

This is a very important phase and is crucial to the success of your project. This phase is many times neglected as it can be time consuming when done properly.

  • Firstly, you would need to do a proper information gathering of what software, roles and services are being used on the servers, how they are configured and how they connect to the network (Both LAN and WAN).
  • You need to identify any problems that are currently on the servers and resolve them before you start with the execution phase.
  • Identify any compatibility issues. Make sure the software that you will be installing on the new servers are compatible with the operation system (Eg. MS Server 2008 64bit). Should you be installing the 64bit version of Windows or make use of virtualization technology, make sure that your hardware supports this.
  • Identify all risks related to the project. This includes anything that may prevent a successful execution of the project.

  2. Preparation

Preferably you would like to do as many tasks as possible as part of your preparation phase to ensure that you have everything ready before you start with the execution phase.

  • Images and Backups. This is crucial and should never be overlooked. It is recommended to make images alongside your daily backups before the project. With images you can usually get your system back to a certain state much quicker than with conventional backups.
  • Prepare your hardware. Check and test all hardware, make sure that the server has the correct specs and create your RAID.
  • Prepare your software. Make sure you have all the software and license keys for the necessary installations. This includes installation disks that might be needed to decommission certain servers / services. Contact 3rd Party vendors and arrange with them for the necessary installations.
  • Communication. Communicate expected downtime to the users as well as any changes the users might experience after the new servers are implemented.
  • Get all the necessary technical documentation that you migth need.

  3. Execution

Most of the time the execution phase can only start when you have network downtime (Users no longer working on the system). Remember to make a final backup before you start with the execution phase. This can be an incremental backup to save time. Do this as soon as you have network downtime and ensure that there are no users working on the system.

You will now install and configure your new servers. We recommend that you follow Microsft best practises to install and configure your servers – See our Best Practises section for detailed information on this.

It is very important to plan your time frames correctly. Start tasks that require the most time first (Data copy, mailbox moves etc.). Document all the settings that you configured (Passwords, account details etc.). Allow enought time for the 3rd party vendors to install their software.

It is often a good idea to try and keep the computer name the same if you are replacing servers. It elimanates a lot of workstation work and additional configuration changes that might need to be made.

  4. Testing and problem solving

Once you have completed your execution phase be sure to test all relevant services. Allocate enought time for this so that you can resolve any problems that might arise. Be sure to test the services both internally and externally and from all necessary devices.\

After you have done all the testing and you are sure that all is working you can decommission your old servers. You might need the original installation disks to do this (Exchange 2003, SBS2003 etc.)

You can download the accompanying Project Workflow and Site Analysis Checklist which you can modify according to your requirements.