Announcement

Collapse
No announcement yet.

Application log filling with Event IDs 1058 and 1030 after rebooting Server

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

  • Application log filling with Event IDs 1058 and 1030 after rebooting Server

    I rebooted the main DC with all FSMO roles for a single domain Forest a week ago and since then, the event viewer's application log has been filling up with the below.

    Event Type: Error
    Event Source: Userenv
    Event Category: None
    Event ID: 1030
    Date: 19/03/2009
    Time: 03:17:33
    User: NT AUTHORITY\SYSTEM
    Computer: DC WITH ALL FSMO ROLES
    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.
    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.



    Event Type: Error
    Event Source: Userenv
    Event Category: None
    Event ID: 1058
    Date: 19/03/2009
    Time: 03:17:33
    User: NT AUTHORITY\SYSTEM
    Computer: DC WITH ALL FSMO ROLES
    Description:
    Windows cannot access the file gpt.ini for GPO cn={084827D0-F077-442B-9633-
    B863304819AB},cn=policies,cn=system,DC=domain,DC=l ocal. The file must be present at the
    location <\\domain.local\SysVol\domain.local\Policies\{08482 7D0-F077-442B-9633-B863304819AB}
    \gpt.ini>. (Access is denied. ). Group Policy processing aborted.
    For more information, see
    Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    I have checked security permissions, no DFS is used on the network etc. Have googled for the above but posts don't seem to be relevant to my situation. There are no problems on the domain.

    Is there anyway of seeing what GPO name the GUID refers to? If that policy isn't in use, would I be best deleting it?

    TIA

  • #2
    Re: Application log filling with Event IDs 1058 and 1030 after rebooting Server

    Found this regarding my last question.

    http://support.microsoft.com/kb/216359

    Any advice or further thoughts appreciated.

    Comment


    • #3
      Re: Application log filling with Event IDs 1058 and 1030 after rebooting Server

      If you open up GPMC, expand Group Policy Objects and select each GPO, then select the details tab in the right pane you'll see the unique ID (guid) of the GPO. This will help you identify the GPO in question. If it turns out to be the Default Domain Controllers GPO, make sure that the Enterprise Domain Controllers group has READ and APPLY permissions. For all other GPO's the Enterprise Domain Controllers group should have READ permissions.

      Comment


      • #4
        Re: Application log filling with Event IDs 1058 and 1030 after rebooting Server

        Originally posted by joeqwerty View Post
        If you open up GPMC, expand Group Policy Objects and select each GPO, then select the details tab in the right pane you'll see the unique ID (guid) of the GPO. This will help you identify the GPO in question. If it turns out to be the Default Domain Controllers GPO, make sure that the Enterprise Domain Controllers group has READ and APPLY permissions. For all other GPO's the Enterprise Domain Controllers group should have READ permissions.
        Thanks Joe. Carried this out and the problem policy is one for 'Windows Update' settings. As I transitioned from SBS about a year ago, I still have GPOs left from there, so some settings have their own GPOs.

        I was tempted to configure the 'automatic update' settings in the Default Domain Policy and delete the policy. What do you think? Domain controllers only have read permission to it and not apply.

        Am I best to configure the 'automatic update settings' for the DC in the DC policy?

        Comment


        • #5
          Re: Application log filling with Event IDs 1058 and 1030 after rebooting Server

          Hi,

          Have you come across this yet: http://support.microsoft.com/kb/842804

          SBS related? : http://support.microsoft.com/default...888943&sd=dell

          Ta
          Caesar's cipher - 3

          ZKHQ BRX HYHQWXDOOB GHFLSKHU WKLV BRX ZLOO UHDOLVH LW ZDV D ZDVWH RI WLPH!

          SFX JNRS FC U6 MNGR

          Comment


          • #6
            Re: Application log filling with Event IDs 1058 and 1030 after rebooting Server

            Originally posted by L4ndy View Post
            I haven't come across those. Thanks L4ndy. SBS one is not relevant to me but the top one is worth me taking a look at. However, I don't want to do anything drastic has nothing has been effected on the domain and automatic updates are functioning ok.

            Do you think deleting the problem policy and adding the settings to the Domain wide policy would be a feasible option?

            Comment


            • #7
              Re: Application log filling with Event IDs 1058 and 1030 after rebooting Server

              I'd just give dfsutil /purgemupcache a go first.

              And maybe follow this steps if relevant: http://support.microsoft.com/kb/887303

              Ta
              Caesar's cipher - 3

              ZKHQ BRX HYHQWXDOOB GHFLSKHU WKLV BRX ZLOO UHDOLVH LW ZDV D ZDVWH RI WLPH!

              SFX JNRS FC U6 MNGR

              Comment


              • #8
                Re: Application log filling with Event IDs 1058 and 1030 after rebooting Server

                Originally posted by L4ndy View Post
                I'd just give dfsutil /purgemupcache a go first.

                And maybe follow this steps if relevant: http://support.microsoft.com/kb/887303

                Ta
                Thanks L4ndy. I'll give it a go first of all.

                The command isn't going to effect anything is it? I won't hold you to it. As it is just a cache, I assume not.

                Comment


                • #9
                  Re: Application log filling with Event IDs 1058 and 1030 after rebooting Server

                  Used dfsutil /purgemupcache

                  Can now safely say that it has worked.

                  Thanks L4ndy and Joe. As ever, your advice saves a lot of heartache.

                  Comment

                  Working...
                  X