Monday, December 03, 2007
Monday, October 22, 2007
But one update is that I received the MVP Award for Directory Services again, this is my ninth year in a row... Which means I must get a life :)
Monday, August 13, 2007
Tuesday, July 24, 2007
Do not mix staging folders and prestaging. They are completely different things!
I got the below from my friend Thomas Bittner, it was written by his team for the APS (All Purpose Server) guide.
Staging folders are used to isolate the files from the changes on the file system, and amortize the cost of compression and computing RDC hashes across multiple partners.
Here is some background on current staging space management. There are three values that are important to staging space management.
· Staging size in MB (configured per-replicated folder in AD)
· Staging low watermark percentage (configured per-server via WMI, applies to all replicated folders on the server)
· Staging high watermark percentage (configured per-server via WMI, applies to all replicated folders on the server)
DFS Replication will do roughly the following when trying to stage a file:
· Request a reservation for staging space for the file based on an estimate of the file size.
· If the currently used staging space is less than the configured staging size, the file is allowed to stage regardless of the reservation amount. This allows large files to replicate and not get stuck with the familiar “huge file” replication blocker on FRS. The reservation amount is accounted for in the used staging space.
· After staging completes, DFS Replication fixes up the reservation amount by using the actual used amount. Note that due to compression, there could been different file sizes.
· If the used staging space is higher than the high watermark, staging space cleanup is triggered. Staging space cleanup will clean up until it hits the low watermark or there are no more files that are candidates for cleanup i.e., all files in staging are actively being used. Note that the cleanup is on a per replicated folder scope.
There are several factors that affect the size of staging. Without going into theories, here are some rules of thumb:
· It is desirable to set the staging folder to be as large as possible (as available space) and comparable to the size of the replicated folder. Hence if the size of the replicated folder is 24.5 GB, then ideally a staging folder of comparable size is desirable. Note that this amortizes the cost of staging and hash calculation over all connections. It is also a best practice to locate the staging folder on a different spindle to prevent disk contention.
· If staging cannot be set comparable to the size of the replicated folder, then reduce the size by 20%. Depending on how well the data compresses, staging files will be 30-50% of the original file size.
· Note that the mentioned two recommendations are particularly important if all the data is preexisting and DFS Replication must process all content at the same time during initial replication. On the other hand, if the replicated folder is relatively empty and gradually grows over time, the recommendation is to determine the projected size of the replicated folder and size the staging appropriately.
· If the size of the staging folder cannot be set proportional to the size of the replicated folder, then increase the size of the staging folder to be equal to the five largest files in the replicated folder.
Make sure that the primary member has the latest version of each file. This is done during configuration of replication because it will be seen as authoritative during first replication. This is similar as doing a D2/D4 restore of a broken sysvol.
During first replication these things will happen:
[P1 = Primary]
[M1 = Member]
File1 exists on both P1 and M1 and are identical = File is not replicated, but metadata is to update the replication DB on M1.
File2 exists on both P1 and M1, but is newer on P1 = File2 will be replicated, and the file on M1 will be treated as a conflict and moved to a special folder called something like "conflict or deleted"
File3 does not exist on P1, but gets created on M1 during first replication = File3 will replicate to P1.
File4 exist on both P1 and M1, but gets deleted during first replication = The deletion doesn't replicate.
Tuesday, July 17, 2007
Have you ever installed a 64-bit OS for personal use? If not, think twice!
I just got my new Dell machine, dual-core 4GB RAM and all sorts of goodies (but NO fancy graphics card, it will only be used as a test machine for servers). Ok, I ordered it with XP 64-bit from Dell, but I forgot to order the darn wireless card. So I thought you could call Dell, tell them that you just ordered a new machine from them and give them the specs...
How stupid was I!!!! First they say that they have no wireless card that support 64-bit, so I told him there was an option during the "configure my computer" wizard that had an option for a wireless card. He says, NO we don't have any wireless cards that supports 64-bit.
Now I'm getting a bit worried, so I (during the time I was on the phone with him) ran through the wizard again and did some screen shots and sent them to him. He says that it is impossible, which forced me to ask him:
"So you have a NIC that customers can order with the wizard that will not work when the computer arrives?"
"Yes, but people should know what they order"
Which I replied to:
"But I had to tell you what a 64-bit OS is! And you are selling these things!"
"You need to call another NIC supplier."
So, I went to MS website and scrolled through the HCL for 64-bit XP, and guess what! There is a Dell card that will work! But unfortunately the Dell website actually lists 2 NICs with the same name and on the HCL the one that is NOT manufactured by Dell is the one that will work on 64-bit. (The name on Dell's website is 1450)
You get the correct hardware from the HCL, the company that sells them have 2 NICs available with the same name and NO specs so you can't tell which one is supported or not!
Guess what, I will not order a Dell NIC, I will find another manufacturer on the HCL and order from them......
BTW - Next post will be DFSR in R2....
Ok, back to work now :)
Sunday, April 08, 2007
So, what am I doing during these short stays you might wonder.... Well, in Johannesburg, South Africa we realized that we wasn't told the whole truth about the environment... Let's just say new forests and domains was discovered so we thought that it would be better if myself and Wolfgang, who is responsible for Exchange, would be the ones going to the major locations and do some discovery work, i.e. run our scripts to find out the details and the truth about the environment.
So what we will be doing the next 12 days is a trip around the world... And people were impressed by doing it in 80 days.... :)
Monday, March 05, 2007
Wednesday, February 21, 2007
This morning I received an e-mail confirming a new contract, basically I will be travelling the next 18 month doing a massive forest/domain consolidation/migration. Hopefully I will have time to post some interesting things that will be discovered during this work and post it here. At this point I have no knowledge about exactly how big it is, but I do know we are talking about 100s of DCs... Which will be some good fun :)
At the moment my schedule looks like this:
- Feb 28 thru March 3 in Germany
- March 11 thru March 16 in Germany
- March 18 thru April 27 in South Africa
After that I will know more about what needs to be done and also the travel plans for the next few months...
...Oh if you are interested I will post a few "findings" I did when I had to do LCS troubleshooting which is very interesting/strange/goofy...