1. You are viewing our forum as a guest. For full access please Register. WindowsBBS.com is completely free, paid for by advertisers and donations.

WinNT to Win2K Profile Problems

Discussion in 'Legacy Windows' started by Cliff, 2002/09/18.

Thread Status:
Not open for further replies.
  1. 2002/09/18
    Cliff

    Cliff Inactive Thread Starter

    Joined:
    2002/09/18
    Messages:
    2
    Likes Received:
    0
    First off, let me say that I am not a PC pro so I'm a bit lost. Nor are we the MIS dept - we do not control the servers.

    We are migrating end users from WinNT to W2K. Our MIS dept has set this up so that the same profile directory is used in both our WinNT domain and Win2K domain. To "convert" a user, we go into Active Directory Users and Computers and activate an account that has been set up. All users are "power users ".

    Here's the problem: After activating the Win2K account and logging in through the W2K domain, some users are unable to do much of anything unless they are granted Administrator privileges. They cannot use any Office 2000 programs, use Outlook/Exchange, print, or retain desktop and other setting from one login to the next. When the same person is logged into our WinNT domain, using the exact same profile directory mind you on the same PC, there is no problem at all, (except that there is no access to the exchange server, but I'm told to expect that). If the person's privilege level is raised to Admin from Power User, then login to the Win2K domain goes fine and the person can function as normal.

    When logging into the W2K domain with anything other than an Administrator privileges, the user gets these error messages:

    In application log:

    Event Type: Error
    Event Source: Winlogon
    Event Category: None
    Event ID: 1012
    Description:
    The automatic certificate enrollment subsystem could not access local resources needed for enrollment. Enrollment will not be performed. (0x80070005) Access is denied.


    In system log:

    Event Type: Error
    Event Source: DCOM
    Event Category: None
    Event ID: 10001
    Description:
    Unable to start a DCOM Server: {834128A2-51F4-11D0-8F20-00805F2CD064} as /. The error:
    "The system could not find the environment option that was entered. " Happened while starting this command:
    C:\WINNT\System32\MDM.EXE -Embedding

    Any help would be appreciated. I'm desperate!
     
  2. 2002/09/18
    Newt

    Newt Inactive

    Joined:
    2002/01/07
    Messages:
    10,974
    Likes Received:
    2
    Both are permissions issues and both are probably from something MIS set wrong with the AD user permissions. I'm not nearly savvy enough on all the AD stuff to give specifics though. Bursley or AndyO maybe could.

    I can't find much useful information on your Winlogon error but have found reference to several other Winlogon 1012 errors (slightly different) and all were permissions problems or "domain not found" problems.

    The DCOM one is for sure though. Get the MIS folks to take a look at Minimum NTFS Permissions Required for IIS 5.0 to Work - Q271071.
     
    Newt,
    #2

  3. to hide this advert.

  4. 2002/09/20
    Cliff

    Cliff Inactive Thread Starter

    Joined:
    2002/09/18
    Messages:
    2
    Likes Received:
    0
    We managed to resolve the problem, though I'm not sure how elegant the solutions are:

    1. We figured out the problem has something to do with permissions associated with our roaming profiles.

    2. Sledge hammer approach: Delete ntuser.dat and ntuser.dat.log from user's profile directory that resides on server and replace them with new versions that we know work. Be sure to delete user's roaming profile from ALL local PCs. If you don't delete the local profiles the new and old ntuser.dat files are merged at login and the problem remains.

    3. Some what more elegant. Have a person with domain administrator rights log into a PC - any PC in network. Open regedt32 and navigate to the top key in the HKEY_USERS hive. Select Registry > Load Hive and navigate to the users NTuser.dat on the server. Load it and select Security>permissions. At this point we found out that the affected users did not have permission to modify they're registry files under their new account name, so we gave Everyone "full control ". Next we went to Advanced options and reset permissions through the rest of subsidiary registry tree. Then we unloaded the ntuser.dat files from the registry and logged the user back in without deleting the local version of the roaming profile. It worked

    Cliff
     
  5. 2002/09/20
    Newt

    Newt Inactive

    Joined:
    2002/01/07
    Messages:
    10,974
    Likes Received:
    2
    Glad it worked and thanx for the two approaches. Interesting.
     
    Newt,
    #4
Thread Status:
Not open for further replies.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.