Deploying Printers by using GPO, no delete old printers correctly RRS feed

  • Pregunta

  • Hello

    We have an Active Directory Domain Services with two domains.
    The current Forest and Domain functional level are Windows Server 2003

    Recently, we've added Windows Server 2008 x64 DC in one of these domains. In order to complete this procedure, the schema was upgraded correctly.

    Then, we configured GPO for deploying shared printers, per machine and users object.
    This implementation was performed based on following Microsoft article:

    Few days ago, we’ve moved the print services to a new server (from Windows 2003 SP3 to Windows Server 2008 x64). The new print server is the new DC Server (2008 x64) and has installed the Print Services Role.

    Actually, a GPO connects the printer per machine and has two printers configured; startup script runs “pushprinterconnections.exe” file (6.0.6002.22314 version). This GPO doesn’t connect printers per user.

    The GPO must connect only the new printers, but we're noting the following problem:
    the workstations randomly are connecting the old and new shared printers.

    Workstations affected by this GPO, have Windows 7 with SP1 and the Domain Controller servers are registering this error in application event log:

    Log Name:      Application
    Source:        SceCli
    Date:          6/24/2011 3:22:45 PM
    Event ID:      1202
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          N/A
    Computer:      ******
    Description: Security policies were propagated with warning. 0xb : An attempt was made to load a program with an incorrect format.
    Advanced help for this problem is available on Query for "troubleshooting 1202 events".

    Additionally, I’ve executed on DCs the GP Modeling and GP Results for affected workstations:

    GP Modeling correctly is showing printers configuration (two printers configured), but GP Results it isn’t doing:
    GP Results is showing all the older printers configured on the past and newest, on all workstations.

    We need to solve this problem ASAP.
    Any suggestion will be appreciated.
    Thanks a lot!

    viernes, 24 de junio de 2011 19:01


Todas las respuestas

  • This error message can occur if the Local Group Policy log files are corrupted. This usually indicates that the secedit.sdb file is corrupted


    Please move one of your Windows 7 computers to another OU without these policies. After minutes run GPUPDATE /FORCE , restart and review if machine lost connections and printers and if Warning Scecli dissapear of your events.  If warning continuing probably your Group policy log files are corrupted.


    Another test to verify it, is open Local Policies, you may receive the following error messages:

    • “Windows cannot open the local policy database. An unknown error occurred when attempting to open the database.”

    • SceCli Event ID 1202: “Security policies are propagated with warning 0x4b8: An extended error has occurred.”

    This error message can occur if the Local Group Policy log files are corrupted. This usually indicates that the secedit.sdb file is corrupted.


    If there aren't any error after move this machine to another Ou, and its Group policy were lost, move again to its final OU.

    Salu2!, Dani Gracia - Madrid España MCSA/MCSE 2003 Security MCITP: Enterprise Administrator (Windows Server 2008) MCTS: System Center Operations Manager 2005 MVA: Microsoft Virtual Academy MAP: Microsoft Active Professional (2010/2011)
    sábado, 25 de junio de 2011 11:00
  • Hi Dani

    We’ve verified the Local Policy database consistency on several workstations. No errors were detected:


    Initiating INTEGRITY mode...
    Database: C:\Windows\security\database\secedit.sdb
    Temp. Database: TEMPINTEG5640.EDB
    Checking database integrity.

    Scanning Status (% complete)

    0 10  20 30  40  50  60 70   80 90 100


    Integrity check successful.
    Operation completed successfully in 0.297 seconds.


    Anyway, we’re executed this procedure on some workstations. So, the local policy database was rebuilt and same problem persist.

    In most cases, the printers are connected ok, but we can see that default printer is not set.
    Sometimes, the shared printers on old server appears, and one of them as default printer.
    Is important note that the old shared printers now doesn’t exist. The old server doesn’t have the printers installed now.


    For diagnostic purpose, we moved some test computers for another OU. This OU is empty, except script logon and startup (we must apply pushprinterconnections.exe for deployed printer changes).

    After the move, when I run GP Results from Active Directory for specific user and computer in Group Policy Management, these are the results for Computer Configuration Deployed Printers:



    Path                                                                 Winning GPO

    \\OldServerIP\simple                                     {9BA332C0-841C-439B-9F66-ED87BF90CFDD},

    \\OldServerIP\doble                                       {9BA332C0-841C-439B-9F66-ED87BF90CFDD},

    \\OldServerName\simple                               {9BA332C0-841C-439B-9F66-ED87BF90CFDD},

    \\OldServerName\doble                                 {9BA332C0-841C-439B-9F66-ED87BF90CFDD},

    \\OldServerName\Canon (doble faz)            {9BA332C0-841C-439B-9F66-ED87BF90CFDD},

    \\OldServerName\Canon (simple faz)          {9BA332C0-841C-439B-9F66-ED87BF90CFDD},

    \\NewServerName\Canon (doble faz)           {9BA332C0-841C-439B-9F66-ED87BF90CFDD},

    \\NewServerName\Canon (simple faz)         {9BA332C0-841C-439B-9F66-ED87BF90CFDD},




    In this moment, the printers are configured by user. Printers per machine now are not deployed. However, the result show all per machine printers configured in the past. Additionally, the policy name is wrong. In this case, the code {9BA332C0-841C-439B-9F66-ED87BF90CFDD} is equivalent to the GPO name configured on original OU (“Alumnos PDP” is the name of GPO).

    This behavior is observed in all workstations with Deployed printers applied.


    Thanks again


    Javier Mariani
    martes, 28 de junio de 2011 20:53
  • GPO it's working right now

    The problem was the roamming profile setted by user

    Javier Mariani
    martes, 25 de octubre de 2011 18:04