- Syncing Local and Domain profiles? Or using roaming profile locall
- Posted by Davey@nozen.net on April 4th, 2006
Is there a way to keep a user's local machine and domain roaming profiles in
sync? Or to use the domain profile when logged in locally?
In specific, a user normally logs into a domain server and has a profile
"username.domainname". However, if the server is inaccessible the user must
log onto the local machine and thus is assigned a different profile
"username" and does not have ready access to the files and settings in his
regular "username.domainname" profile. The files are there... one would think
it'd be easy just to use the "username.domainname" profile seamlessly while
logged on locally but I haven't been able to figure it out.
Any help is appreciated!
Davey@nozen.net
- Posted by Ian on April 4th, 2006
In principle it should be possible to make both accounts load the same
profile if the registry is altered.
HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList
is the place to go. One issue is the need to identify which is which, as the
profiles use SID numbers, not names.
The disadvantage of this kind of thing is that it's not officially
approved..and I've absolutely no idea whether it might give rise to
unexpected problems. Basically, if it breaks, Mr Gates lets you keep both
pieces.
The other safer option is to:
Join the domain, but auto-logon with the local account.
Use MyLogon to connect to the server as/when required.
-------------------------------
An alternative approach to XP network logon - http://mylogon.net
- Posted by Steven L Umbach on April 4th, 2006
As far as the operating system is concerned those user accounts are
different identities. However if the user has folder [NTFS] permissions to
folders in the domain profile he will be able to access the folder by
browsing to it while logged on as a local user. That would not be the case
by default and a local administrator would have to give the user those
permissions. If the domain controller can not be contacted then a user could
still logon to his domain account if cached logons are available [they are
by default] and the user had logged into the domain at least once before on
that computer. The ability to do cached domain logons is configured as a
security option in Local Security Policy or the domain level GP that is
enforcing that setting. --- Steve
"Davey@nozen.net" <Davey@nozen.net@discussions.microsoft.com> wrote in
message news:BD812B52-02D1-4F2F-BA2D-3AA27DDAFE96@microsoft.com...
- Posted by Davey@nozen.net on April 4th, 2006
Cached logins sounds like it might be what I'm after. But last night I tried
unplugging the network cable and the local machine complained that the domain
controller was not available so I couldn't login. These are fresh installs of
2003 server & XP pro, and I haven't changed any security setting. I'll
double-check tonite. You mean the "Number of previous logins to cache" option?
I'm kinda new at this but I'm trying to 'painlessly' migrate a non-profit
(not-computer-savvy) office from a workgroup to a new domain controller.
Thanks
--
davey@nozen.net
"Steven L Umbach" wrote:
- Posted by Steven L Umbach on April 4th, 2006
Yes that is the security option I am referring to and by default it should
be set at ten. However the user must have successfully logged onto the
domain at least once before and show a user profile for the domain user
account on the computer they are trying to logon to. Also make sure that DNS
is correctly configured for Active Directory as that is a must for
everything to work right. A common mistake is to include ISP DNS servers as
preferred/alternate DNS servers on domain computers either through DHCP or
statically configured and as shown with the command ipconfig /all - only
domain controllers must be listed. Domain controllers must point only to
themselves and/or other domain controllers as their DNS server. See the link
below for great info on configuring DNS for Active Directory. --- Steve
http://support.microsoft.com/default...en-us%3B291382
"Davey@nozen.net" <Daveynozennet@discussions.microsoft.com> wrote in message
news:38D381F0-B3B1-47F5-8DA7-B03024FECB5C@microsoft.com...