Local and Roaming Profiles

I just started working on a project at a new company and noticed that they handle local and roaming profiles in an unusual way. First of all, I'm not a Sys Admin by any stretch of the imagination. But as I understand it, with roaming profiles, when the user logs into the system, the system will check which profile (local or roaming) is more current (up to date) and use that profile. When the user logs off, the local profile is copied back to the server. This organization copies the profile down to the workstation when the user logs on and copies the local profile to the server when the user logs off. But they also have a policy setting to delete the local profile after being copied to the server when the user is in the process of logging off. Now if for any reason the server with the roaming profiles is not available and the user logs into the system, he/she will only get a brand new local default profile. Absolutely none of his/her settings such as printer settings, custom Word settings etc. will be available. I asked the sys admin why this was done and he could not give an adequate explanation other than that's the way it's always been done.

So, my question is why would an organization always delete the local profile after copying it to the server when the user is logging off?

Security perhaps?
Though simply deleting the local profile only stops the casual snoop, not someone determined to recover the information.

Or maybe they got burned with corrupted profiles around daylight savings time shifts and this was their hacky workaround.

Security reasons could be a possibility. But the company is very security conscious. They have a policy which requires the end user to lock his/her workstation if he/she is 6 feet or more away from the workstation, even if he/she has full view of the workstation. And they enforce this policy. So, a casual snooper may not figure into the deleting of the local profiles.

I was looking at this from a disaster recovery viewpoint. What if the server with the profiles failed and we had to get the users fully operational ASAP? With nothing more than a brand new default local profile, we would have to reconfigure MS Outlook, make the necessary customizations to Word etc. Whereas, if we had a good recent copy of the profile on the local workstation, we could eliminate a lot of manual labor such as "touching" each workstation to configure Outlook etc. All that would need to be done is change the drive mappings and redirect the printers. This could quite possibly be automatically done. Bottomline, IMHO, having a good recent copy of the profile on the local workstation would make life much more bearable in case of a catastrophic loss of a server.

Security reasons are the most likely reason especially if the company is very security-conscious. You can never be paranoid enough.

Having "backups" of the profile on local workstations sounds like a very flaky approach to disaster recovery to me. A good disaster recovery strategy involves a backup server in a physically different location from the primary server, having both servers be error-resistant through UPSs, RAID arrays and similar, as well as regular long-lasting backups of the server data.

Actually, using roaming and local profiles in this manner is what is recommended in Microsoft's IT Professionals hand book for system administrators. Unfortunately, the company and the sys admin don't follow MS guidelines.

The local profile really isn't a backup. When the user logs into the system, the roaming profile is copied down to the workstation and used. When the user logs off the system, this profile is copied back to the server. It is not deleted. The copy that is on the workstation is referred to as the local profile. MS states in the manual that the time stamp of the local profile is compared to the roaming profile and whichever version is newer will be used. It also states that if the server is not available then the local profile will be used. But in this case, the company always deletes the local profile when the user logs off. Thus, in a server failure, the end user will only get a default unpopulated profile.

Also, Veritas has a published white paper on RAID a while back. They state that the probability of catastrophic loss of a RAID 5 server, which is today's industry standard is about 1 in 100,000 if memory serves me correctly. But the probabiity was really low. So, based on the probability, it's very unlikely that this will occur. But the odds drop drastically when you lose one drive in your array. You're somewhat vulnerable until the defective drive is replaced and the data is resynchronized which may take up to 48 hours. during the 48 hour time period, the probability of a catastrophic loss drops down to about 1 in 10,000.

But even so, I know that the upper level people will start looking at a contingency plan and there will be a lot of "What if" questions. So, the only thing I'm not sure of is this local profile issue.

So I'm guessing that the person who made the "delete the local profile" decision has long since departed from the company?

From what I'm told one of the many previous Sys Admin's changed the policy to delete the local profiles. But because of the high turnover, the current Sys Admin may not want to get involved and offer any input. In other words, ignorence is bliss. For all he knows, I'm may be just a contractor brought in to "clean house". Couple that with the fact that all contractor's must complete the required work in 6 weeks and be gone. It's just not an environment to create any trust with the EDP personnel. No, I'm not here to get anyone fired. I've just been directed by the lead to get a thorough understanding of the operations "just in case" there is any discussion by the organization's upper management about a contingency plan.

I'm no system administrator but I just can't see any legitimate business reason for deleting the local profiles. What concerns me is if the recommendation to NOT delete the local profiles is implemented and after the fact it is discovered that deleting the profiles did in fact resolve some mission critical issue. Well, you can picture the scenario.