Endpoint Protection

 View Only
  • 1.  SEP client causing an event ID 1058 and preventing Group Policy objects from running on client PC

    Posted Aug 14, 2009 06:43 PM
    We have SEP server running on a Server 2003 x86 box, running version 11.0.4202.75 and our clients are on the same version.

    We use group policy to push out "pushprinterconnections.exe" for use with print management on a Server 2003 R2 box. This works for about 50 client PCs, but fails on about 10 of them. The error logs on the failing PCs are follows:

    Event ID 1030:
    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.

    followed by

    Event ID 1058:
    Windows cannot access the file gpt.ini for GPO cn={73A559D8-A303-406A-A7D4-EEA225B76119},cn=policies,cn=system,DC=(domain name),DC=corp. The file must be present at the location <\\(domain name)\SysVol\(domain name)\Policies\{73A559D8-A303-406A-A7D4-EEA225B76119}\gpt.ini>. (The specified network name is no longer available. ). Group Policy processing aborted.

    I found the following article:
    http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/ff7a6be8-28d0-4100-bf38-8087fbac6f6d

    and tried uninstalling the symantec client. Bam, works instantly on the PC's that had failed with the formerly mentioned Event ID's.
    Any idea why this is happening?

    We've also been having a lot of problems with users not having their drives mapped when they login, the home drive and a few other network drives that we map via login script will occassionally just not map. I had no clue what could've been causing this until now- now I think it might be the SEP client.

    Any info on this issue would be greatly appreciate, thank you.


  • 2.  RE: SEP client causing an event ID 1058 and preventing Group Policy objects from running on client PC

    Posted Aug 14, 2009 07:52 PM
    Were the 10 PCs that did not work initially had a common?
    Like same Computer hardware brand... OS maybe?
    from there you mmight see a trend...

    Also, your SEPM version is already MR4 MP2 already so version doesn't count... 

    thanks... 


  • 3.  RE: SEP client causing an event ID 1058 and preventing Group Policy objects from running on client PC

    Posted Aug 15, 2009 04:22 AM

    Could you please tell me what are the components that are installed for the SEP Cleint.

    If the Network Threat Protection is Installed then remove NTP and see if it works or not. If it works then we have make exception in the firewall rule.

    In order to remove the NTP go to add remove program , Select Symantec Endpoint Protection and Click then Modify the install. Uncheck the NTP from the custom install settings..



  • 4.  RE: SEP client causing an event ID 1058 and preventing Group Policy objects from running on client PC

    Posted Aug 17, 2009 01:22 PM
    Same brand (Dell) different models. No hardware similarities.

    We have NTP, AV/AS and PTP. I've checked the NTP logs and there are no entries that fit the issue, but I'll try manually removing NTP and leaving the others in place.

    What I am stumbling over is that this issue doesnt affect any other systems- just this small handfull. If it were a firewall configuration issue why is it not affecting anyone else?

    I'll remove NTP and update you.


  • 5.  RE: SEP client causing an event ID 1058 and preventing Group Policy objects from running on client PC

    Posted Aug 17, 2009 01:49 PM
    Did you read this MS KB?

    Client computers record Event ID 1030 and Event ID 1058 when DFS is not started on a Windows 2000-based domain controller -

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

    I hope this is helpful.

    Thomas




  • 6.  RE: SEP client causing an event ID 1058 and preventing Group Policy objects from running on client PC

    Posted Aug 17, 2009 05:56 PM
    Cycletech, thank you- yes I had read that article and that service is started on both our DC's.

    One of the PC's that was having this issue last week pulled the "pushprinterconnections.exe" policy just fine this morning, and it showed in the SEP NTP log as a successful connection. These never showed up in the logs previously as blocked connections. Why?

    Could a SEP module other than NTP be blocking this?
    I looked again at other machines this morning and the other few that are still not receiving the policy have absolutely nothing in their logs to indicate a failure, yet if I remove SEP completely it works no problem.

    Definitely frustrating.