I have to admit that I was surprised to see the number of responses I got to my initial discussion on the concept of Roaming Users. A great number of people wrote me with success stories, some even getting into details on their plans. Most of these people, though, were in smaller environments. In the environments where there are more than 1000 users, there are similar hurdles to get over, they are just much larger.
I wanted to expand on the thought process that got me wrapped up in roaming profiles, so I went back to the drawing board to try and collect a few more topics for consideration and discussion, here they are:
1. When you are going to put together the plan for this type of an implementation, you need strong people around you. The two most important people are the guy with the iron fist and the pessimist.
First, the guy with the iron fist has to have vast technical knowledge and the respect of those in the business. He has to be willing to tell people that, "this is the new system, and if you don't like it, too bad." He has to understand the implications of all of the decisions he is going to make, so that they are not poor ones, and he also has to have the ability to live with his mistakes.
The other guy, the pessimist, is someone who understands the technology and always paints the worst picture. This is important because this guy will help you to cover all of the bases ahead of time. There was a guy like this at my old place of employment, his name is John. He was really uptight, but that helped us to discover issues before they arose.
2. Standardize on the OS build and the software to be laid on top of that (out the door). A good time to implement roaming profiles is during an upgrade. If you are rebuilding your environment, you will have the capability to build a standard from your lab. Come up with a core set of software to lay on top of your OS, and build all machines from the same image (if they are the same hardware, you could even ghost the process).
3. Come up with a software catalog that people will be able to install from and test all software compatibility on that catalog. After that, lock it down. There should only be two or three people that have the power to add software or updates to your environment. Any time that you will have an entry to that catalog, remember to test thoroughly.
One suggestion is that you create a machine with the standard OS build on it and continue to load all new software onto that machine. Try to keep this machine alive as long as possible (this will be difficult), as it will be the best mirror of your environment you can have. If it dies at some point (which, like Elvis, it will), rebuild another using the same method.
Also something to think about is the creation of a standard package for your DLL's. This could be updated as needed by the same people that have access to the catalog.
These were the thoughts that cluttered my mind for quite some time, feel free to add to them with ideas of your own.
Once again good luck with your implementation and keep the feedback and stories coming.