Weekend Open Thread > Dang

reply to nnaarrnn

Re: Dang

We did that a few weeks ago on a Friday night, ended up getting O/T pay from 5pm through till 11:30pm. It was a LOT of work...and we're still running into issues now that we're trying to get users to log on using their domain acct (migrating local user profiles to domain acct).

By any chance do you know the proper way to migrate a local user profile to a domain profile and keeping their data intact?
--
Sriram Satish
NYU Stern School of Business
Faculty of Arts and Science CIT

reply to sansri88
Assuming Roaming Profiles:
Assuming Workstation is on domain:
For me, the following prevents every problem that might come up:

Boot into Administrator (local or domain). Immediately copy the user's profile to it's home on the roaming profile server.
I normally use xxcopy, as it continues on fail and you can F3 the command to get files that might be temporarily locked.

Make sure ntuser.dat(s) and ntuser.ini in %UserProfile% are copied.

sample xxcopy command, as run from Profile server:
xxcopy "\\workstation\c$\documents and settings\userprofile\*.*" d:\profiles\usergroup\username\ /s /h /bi /f5 /yy
Switch documentation and exe avail at »xxcopy.com

I prefer to rename the profile folder to the domain user's name, if it isn't already.

Reset domain profile folder ownership on all files to Domain Administrators group(NOT to the Domain Administrator).
Reset domain profile folder permissions on all files to Domain User or Domain User's group.
Not always needed but these 2 steps save me a ton of profile load headaches.

Also: Dropping the domain user account into the workstation's local administrator's group can help smooth a 1st profile load. After that you can tweak back the user permissions. Usually this isn't needed.

Rename/Move profile folder still residing on workstation (or delete if you feel gutsy).

Reboot workstation and logon w/ domain user account.

I know this seems like a lot, but I adopted each of these steps through trial and error. Together, they've wiped out nearly 100% of my roaming profile issues. Especially in WinXP & Server 2003 domains.

NV
--
In my perfect religion, a giant hole appears and sucks up all the lousy people.
I call it the Crapture.

A few potential problems with this approach:

Depending on settings/policies/GPOs, the files' owner may need to be the target/logged in user, not the domain admin group. setacl is a good and free utility for setting this.

Registry entries likewise may need ownership or ACL changes; these are stored in ntuser.dat. I don't know for 100% certain, but I believe this is what the "copy profile" GUI/utility does (in XP Pro, maybe others) when you fill in the "allowed to use this profile".

My suggestion would be to do just that: log in as an admin, possibly/preferrably a domain admin (so that setting SIDs and ACLs shouldn't be a problem either with the workstation or on the profile server) so that the profile won't be in use. For extra "not in use" safety, do this after a fresh reboot. As someone else suggested, a Safe Mode reboot (obviously with the "with networking" option) has the best chance of working w/r/t this, as nothing that starts automatically (services, AT jobs, Task Scheduler, etc.) will have a chance to hold open those profile files. I'll also add I was surprised that logging in only a single time as the user I wanted to copy was sufficient to make some of the files in use, and could not be cleared except by rebooting. Use the copy profile GUI to copy the profile up to the profile server, and especially remember to use the "allowed to use" option with the target domain user so that any filesystem and registry object SIDs and ACLs will be updated accordingly.

Note that this is all theory, because I've never had to do precisely this, and I have been laid off from the environment in which I could have tested this before posting it. I also have not had any admin experience for Vista or Win7, so YMMV. What I can report is that under XP Pro and Win2K3 a recursive file copy (as I had done and did work before the domain admins stepped up security somewhat) did not work, whereas retrying with the copy profile GUI did.

I have had a lot of success in the past just recursively copying the profile directory, where there was nothing out of the oridinary like registry ACLs or enhanced security checking going on, so what Noah posted may work.

(BTW, Noah...the third person, gender neutral, possessive pronoun,"its," does not have an apostrophe. So I think you meant to write "...the user's profile to its home on the...")
--
English is a difficult enough language to interpret correctly when its rules are followed, let alone when a writer chooses not to follow those rules.


Jeopardy! replies REALLY suck!

Re: setacl

I guess I come from the opposite perspective, I've seen but never used cacls. I will say that if it can be protected, setacl can manipulate any ACEs for it: services, shares, filesystem objects, registry entries, not sure what else. It can set ownership, list out the ACEs, owner, group, inheritance...just about anything. And it can work with either names or SIDs, your choice. One thing really handy for migrations is changing all that sort of stuff from one user in one domain to the same name in another domain.

As for applicability to migrating a profile directory tree from a local profile to a domain server...not sure is it any better or worse than cacls.

»setacl.sourceforge.net/

There was a service I wanted to start/stop as a "normal" user, and the only tool I knew about at the time which could add an appropriate ACE was setacl; that one is even in their usage examples page.

The program even has ways to back up all that owner/group/ACE information, and restore it later.

Re: its

You asked, "why the correction."

I'll just say that I'm not so presumptuous to know the EXACT intent of ANY writer, just a statistically large probability, ergo the phrasing "I think you meant." As my .sig says, it's a difficult enough life trying to understand people when the rules are followed. To my way of thinking, while I realize there is a certain point where negativity has worse effects, more correct usage begets more correct usage, because the correct way is seen more than the incorrect way. If nothing more, the subconsciouses of more readers see more correct usages, and they will tend to write better, thus reducing misinterpretation possibilities. I realize the gamut of reaction is all the way from appreciation to outright hatred, and I apologize if this offends some.

But that is an interesting flag.
--
English is a difficult enough language to interpret correctly when its rules are followed, let alone when a writer chooses not to follow those rules.


Jeopardy! replies REALLY suck!