Announcement

Collapse
No announcement yet.

Userenv eventID 1030/1058/1005

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Userenv eventID 1030/1058/1005

    I have about 18 dc's in 5 domains in 1 forest... All DC's/DNS servers are Win2k3 and all dc's are global catalog servers as well. Each domain is a tree. We just promoted the forest and all domains to Win2k3 native mode. Just about all machines are functioning properly. All 15 buildings/dc's are able to access everything they need across the domain except 1 building. The rest of the buildings in that domain are working fine. We thought it was a dns error on the dc, so I uninstalled DNS, ran dcpromo down and then reinstalled the active directory/dns as a dc in the existing domain (as it was before). I checked the event log and in the Application log I found these:

    Event Type: Error
    Event Source: Userenv
    Event Category: None
    Event ID: 1005
    Date: 7/8/2004
    Time: 11:40:13 AM
    User: NT AUTHORITY\SYSTEM
    Computer: FBTN_SC-DC
    Description:
    Windows cannot connect to ABSINC.LOCAL domain.
    (Server Down). Group Policy processing aborted.


    Event Type: Error
    Event Source: Userenv
    Event Category: None
    Event ID: 1030
    Date: 07/08/2004
    Time: 11:29:35 AM
    User: NT AUTHORITY\SYSTEM
    Computer: FBTN_SC-DC
    Description:
    Windows cannot query for the list of Group Policy objects.
    Check the event log for possible messages previously logged
    by the policy engine that describes the reason for this.


    I checked to make sure all servers were up, they are. I also checked to make sure that I had a network connection from one to the other, I did. I tried to browse to a shared folder on one of the servers and got "no logon servers are available to service the request". After the reinstall, the machines are able to access files in the shared folders in another domain, but I still have the eventID's in the applog.

    I found the previous errors on all dc's running dns in the forest except for the following.

    On another PDC emulator in another domain I found this error along w/ ID 1030:

    Event Type: Error
    Event Source: Userenv
    Event Category: None
    Event ID: 1058
    Date: 07/08/2004
    Time: 11:29:35 AM
    User: NT AUTHORITY\SYSTEM
    Computer: ROSSNTSVR01
    Description:
    Windows cannot access the file gpt.ini for GPO
    cn={959F5E4D-268C-4FB4-9D22-7596BE3EBD53},cn=policies,cn=system,
    DC=ABSINC,DC=LOCAL. The file must be present at the location
    <\\ABSINC.LOCAL\SysVol\ABSINC.LOCAL\Policies \
    {959F5E4D-268C-4FB4-9D22-7596BE3EBD53}\gpt.ini>.
    (The system cannot find the path specified. ).
    Group Policy processing aborted.


    I browsed from this machine to the file it cannot access and was able to access it... so I don't understand why it is inaccessible. Sorry this was so long, wanted to give as much data as possible... Thanks

  • #2
    already tried http://www.eventid.net/
    Marcel
    Technical Consultant
    Netherlands
    http://www.phetios.com
    http://blog.nessus.nl

    MCITP(EA, SA), MCSA/E 2003:Security, CCNA, SNAF, DCUCI, CCSA/E/E+ (R60), VCP4/5, NCDA, NCIE - SAN, NCIE - BR, EMCPE
    "No matter how secure, there is always the human factor."

    "Enjoy life today, tomorrow may never come."
    "If you're going through hell, keep going. ~Winston Churchill"

    Comment


    • #3
      I have gone thru each solution from the eventID posts and haven't found anything that works.

      Are there any permissions that would not allow a dc from one domain to pull the gpt.ini from another domain? And if so, why can I browse to it from Explorer and open the file but can't access it thru AD?

      Each of our DNS zones are AD-integrated zones with 4 dns servers all registering records in the zone.

      Comment


      • #4
        This is the the kind of errors that I hate the most. Usually it IS DNS related, though sometimes it could be a result of screwed NTFRS replication of SYSVOL share.

        couple of tests that might help you pinpoint the problem:

        1) create a scheduled task on the client experiencing the problem, which will open an interactive cmd shell (by default will run as Local System account). When the window pops up, check if you can resolve/access the sysvol share.

        2) Check out the following KB:
        http://support.microsoft.com/default...b;EN-US;250842
        try enabling verbose logging and drill down the logs for any errors.
        (the article applies to W2K, so you might need to adjust it to your needs - gpotool is depricated in favor of gpupdate/gpresult)

        3) go over the system variables to determine the DC the client used to logon. Make sure the DC is resolvable by FQDN and it's hostname.

        4) Use ntfrsutl.exe with "ds" or "sets" options to make sure the SYSVOL is replicating ok.

        5) Check out that the comuter accounts have at least read access to SYSVOL and the folder where the GPT part of the GPO is located (both NTFS and share permissions)


        Is the building in question configured as separate site in AD Sites&Services ?
        Do the dcdiag and netdiag come up clean on the DC that should serve the building's logons ?
        What happens if you take the DC offline (force the clients to authenticate to other DC) ?
        Guy Teverovsky
        "Smith & Wesson - the original point and click interface"

        Comment

        Working...
        X