Edward, See my comments inline below:
On Sun, Jan 20, 2013 at 3:27 PM, Edward Ned Harvey (lopser) < [email protected]> wrote: > > From: Ski Kacoroski [mailto:[email protected]] > > > > Users can > > easily be migrated via Microsoft tools (keeps all their information and > > profile). > > Thanks for your input - I'd like to know some more detail on the mentioned > MS tools. Any terms I should google for? > > Truly, the one disadvantage that I'm aware of, merging everything into a > single domain, is ... Well, for the finance and HR and managers who just > care about "My Documents" and MS Office, no big deal; they get a new user > profile, they don't really care. But for the developers, engineers, > product verification, etc, who go to a lot of pains to install their > development environment and configure everything "just so," it represents a > real loss of time for them to be forced into a new user profile. So if we > can facilitate that change, without causing too much difficulty for users, > I'd really like to do it. > Ideally, I guess I'd like to see, admin simply joins user's computer onto > new domain, runs some utility to convert TheUser's profile from the old > domain to the new domain. User logs in with the new domain (and possibly > new username or password). Doesn't really notice or care about anything > after that ... It's back to "business as usual" after a few minutes of > hand-holding with some IT staff. Is this too much to hope for? > You're absolutely right about the time that goes into setting things up right for developers and I'm sure they appreciate your concern for their time while seeking a solution. Something I've used in the past to get around users having to completely recreate their profiles is Windows Easy Transfer<http://windows.microsoft.com/en-us/windows7/Transfer-files-and-settings-from-another-computer>. The tool was designed to assist people when moving to a new computer running Windows 7, however you can select individual profiles, which you can then jury rig to move everything over from their old domain user to their new one. The basic process it to export the profile to your local machine, and then import the profile on the same machine, pointing it to their new domain account. There were a couple small quirks (registry doesn't seem to copy over) that we ran into when doing this, but it got the job done. The big X factor in all of this is how large of an environment you're supporting. The tool is not made for the enterprise so it isn't designed to scale. You can probably glue together some sort of solution that would automate this but I'm not sure how you'd go about doing so (I've only had to do this for isolated incidents, never enterprise wide). Ideally there is a better solution available but this should be able to get things done in a pinch. > > The server resources - shares and whatnot - I'm confident we can handle > seamlessly. As you mentioned, trust with the new domain, set permissions > in the new domain based on pre-existing permissions. And then phase out > the old domain. Users generally don't need to know or care. > > > > Apps need to be rebuilt in the new domain. > > I think this was probably just a tangential comment, unrelated to anything > I need to care about. But just to be sure... What do you mean? > No real help here but my take away from that comment was that he meant having to setup the apps to hook into the new AD domain, perhaps copy over data, etc...just my two cents. > > _______________________________________________ > Tech mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
