I guess people don’t like change at the end of the day. They’re comfortable with a mouse and keyboard, and that is tried and proven. That’s where we need pro-active IT people who actually find ways to do things better, rather than just responding to support calls.

Tablet PCs work very well in projects where there is a specific task and there is software supporting that. Tablets have taken computing into places that it was not possible to go before – From meetings to manufacturing plants, aircraft to underground pipes.

There are massive projects going on all over the place every day, but they are not in the sight of consumers, so there is a perception that Tablets have failed.

The large iPhone idea – I think that is where UMPCs are finally going. I hope they make it there before Apple comes up with a Tablet and puts the UMPC manufacturers out of business.

I still like the all in one, and I have done without a PC for years untll now. Now I never get to use my tablets because they’re all out on demo…

First, a couple of questions. Did you create an “Authoritative Restore Point” before making the Staging Path changes? Also, after the change was made, did you see a log entry with Event ID 13563? If so, there were steps in the page you linked to that you have to follow; basically they are:
- set explorer to show hidden files and folders
- from command prompt, run ‘net stop ntfrs’
- Go to the original staging path and copy the files there to the new path
- from the comand prompt, run ‘net start ntfrs’

Also, remember that the changes are made in both the Registry and in the AD system using Adsiedit.

Finally, don’t forget to look in your DFS Replication Event Viewer for Event ID 4208, which means your staging is running out of space. This can be because the stating space defaults to 660MB, and after you account for the space it wants to keep open all of the time, any file over 500MB will not replicate, but will simply clog up replication.

Good luck.

Just remember that you have to enable replication between each server IN EACH DIRECTION. If you setup replication from your original server to the new one, and did not setup replication the other way, or at least replication faster that European Swallow slow, then you would either see no replication back from the new server to the original, or the replication would be so slow as to seem nonexistent.

Go back and check your replication between each of the servers. If you follow the steps under “Adding a New Server to an Existing Share,” just make sure you check all directions.

Works in theory, fucked up in the real world. I did testing such as disabling the nic and watching the fail over. Adding files to the DFS NameSpace lInk and watching those actually show up on the last standing server. Restoring the disabled nic secondary DFS system resulted in, guess what, JACK SHIT. All the new files that were made in the DFS and last standing server are present, yet I am still waiting for the files created during the test outage to replicate.

New files are still replicating between the servers fine.

So this is to prevent outages and keep to folders identical. What a piece of crap, fails miserably at its sole purpose.

As for the template, this is the Digg 3 Column by Small Potato, and it was a regular choice from the “Manage Themes” page. However, I don’t see it listed now. So, I guess you have to get it yourself and load it from there.

Here is what I have found out about those error messages.

The error 13552 is usually stating that FRS could not start, while the error 13544 states that DFS is having an “overlap” problem with your shares.

FRS not starting can happen for a couple of reason. Either because the necessary folders do not exist or because DFS bombed out, and FRS is just following along with it. Most likely, FRS is not starting because of the DFS problem in 13544.

Now, the overlap error is one that happens when you have a folder that is already shared by a higher level folder, which is trying to be a DFS share folder also.

Here is an example for you:

Lets say you have the following folder structure on your D drive…
D:\Shared\
D:\Shared\Groups
D:\Shared\Homes

Now, you have shared the “Shared” folder, so everyone can get to both the Groups and Homes folders. You have set security permissions on the folders under Groups and Homes to keep people out of places they shouldn’t be.

You decide that you would like everyone to be able to go to:
\\Our Domain\Homes
to get to the Homes folder. So, you share the Homes folder itself, go to the other server (your target server) and setup the same folder and sharing layout on it’s D drive. You then create your DFS namespace and setup replication for them… and things don’t work.

The problem is simply because you are now sharing the Homes folder directly, but it was already shared by way of the Shared folder. This is the Overlap that error 13544 dies over.

While there are many ways to fix this, they all depend upon how you are setup. Here is how I would handle the situation. This assumes that you want to share Shared and Homes both under their own names in DFS.

First, remove any overlap DFS Namespace items. Then, make sure the Namespace, folder targets, and replication is setup for the Shared folder. Next, setup a new Namespace and folder targets for the Homes folder, but DO NOT ENABLE REPLICATION FOR THEM. Why? Well, the Homes folder is going to be replicated by way of the Shared folder already, so you don’t even need to try and replicate it again.

This should directly fix the 13544 DFS error, which should indirectly fix the 13552 FRS problem.