none
Printer GPOs fail on some computers but work on others - error code 0x80070034

    Question

  • Hello, I have a couple of GPOs that roll our printers. They have been running smoothly for quite some time, then suddenly started giving our errors on our newer machines. Meaning, the GPOs will work fine on some clients but will not work on others. Also all other GPOs work fine on all clients. The clients are similar Lenovo Windows 7 64-bit machines.

    This is the error: Event ID: 4098, Group Policy Printers. The computer '123.123.123.123' preference item in the 'Deploy printers - {3F6DE6D0-86DC-4D1F-AB99-81BC07F23F3C}' Group Policy object did not apply because it failed with error code '0x80070034 You were not connected because a duplicate name exists on the network. If joining a domain, go to System in Control Panel to change the computer name and try again. If joining a workgroup, choose another workgroup name.' This error was suppressed.

    I turned every stone I could think of on the problematic machines but cannot find out a reason. I disabled anti-virus/firewall, I logged in as domain admin and I tried both user & computer GPOs. No luck. Notice that I can successfully connect manually to the Printer shares (the ones used to distribute the drivers).

    Domain is Win2008 R2. The printers "live" on a Win2012 machine and the drivers come from there. I am using Group Policy Preferences. Ideas are welcome.

    Thanks

    Christos

    Thursday, March 05, 2015 5:43 PM

All replies

  • > connected because a duplicate name exists on the network. If joining a
     
    Seems you have duplicate computer names in your network. This is rather
    not a GP issue.
     
    I'd suggest to carefully examine system and application eventlogs not
    only on affected computers, and double check DNS servers for correct A
    records.
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Sunday, March 08, 2015 11:50 AM
  • These are brand-new installations with brand-new unique names that are being sysprep-ed before deployment. So this is not the issue, the error could be misleading. Also notice that all other GPOs work fine. Other ideas?

    Sunday, March 08, 2015 4:18 PM
  • Hi,

    Since the clients are brand-new installation and no duplicate name exists in the network, I suspect that there's something wrong during the GPP apply to the new clients which could be caused by some particular settings.

    Would you please show us the RSOP xml file of the group policy?

    Looking forward to your reply.

    Best Regards,

    Elaine


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Thursday, March 12, 2015 9:32 AM
    Moderator
  • Hello and thanks for the reply. I can produce a GPresult but this has all GPOs and the XML is circa 2000 lines. Do you want this delivered to you somehow? -Christos
    Friday, March 13, 2015 6:57 PM
  • Upate: The GPO mechanism seems fine, I can confirm this because the TCP/IP ports (for the network printers) get created. So the clients get access to the GPO and they can also process the information but the printer device doesn't get created. It behaves like a driver (installation) problem but as I said, everything works fine if I browse to the network share that distributes the drivers and double-click on the printer. And I do have a GPO that disables security prompts for driver installation.

    Any other ideas?

    Monday, March 16, 2015 9:51 PM
  • Hi Criskrit,

    Would you please check if the drivers you have are fit for the new computers? 

    Maybe the new computers require the 64 bit printer driver, however the drivers you have are 32 bit.

    This might explain why the printers on the old computers are working fine but not the new computers.

    Best Regards,

    Elaine


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, March 24, 2015 2:51 AM
    Moderator
  • Hello and thanks for the suggestion. Yes the drivers are okay, all clients (working and not) run the same Win 7 x64. Let me summarize the situation:

    - The GPO runs because the printer IP ports are created

    - The Printer Shares (that distribute the drivers) are accessible because the printer is installed without any problems/warnings if I manually double click on them (the shares)

    - Security prompts for driver installs are disabled


    I also noticed the following. The error says "The computer '123.123.123.123' preference item in the Group Policy object ... etc" The IP mentioned in that error is NOT the computer/client running the GPO but the IP address of the target printer. So the client thinks the Printer already exists or the IP is already taken (or something of that sort).


    Here is the GPresult XML for this

    <GPO>
      <Name>Printers - deploy - user</Name>
      <Path>
        <Identifier xmlns="http://www.microsoft.com/GroupPolicy/Types">{5C21
    1010-F5E0-445C-99F3-0B8A9D9CB680}</Identifier>
        <Domain xmlns="http://www.microsoft.com/GroupPolicy/Types">mydomain.com</Domain>
      </Path>
      <VersionDirectory>34</VersionDirectory>
      <VersionSysvol>34</VersionSysvol>
      <Enabled>true</Enabled>
      <FilterId>MSFT_SomFilter.ID="{6272C5C1-9C4E-40B7-BD5A-277ED70B337D}",Domain="mydomain.com"</FilterId>
      <FilterName>Any Win Desktop OS</FilterName>
      <IsValid>true</IsValid>
      <FilterAllowed>true</FilterAllowed>
      <AccessDenied>false</AccessDenied>
      <Link>
        <SOMPath>mydomain.com/Configuration/Sites/MainOffice</SOMPath>
        <SOMOrder>3</SOMOrder>
        <AppliedOrder>1</AppliedOrder>
        <LinkOrder>4</LinkOrder>
        <Enabled>true</Enabled>
        <NoOverride>false</NoOverride>
      </Link>
    </GPO>


    Tuesday, March 24, 2015 2:59 PM
  • More info: I noticed another GPO that fails, this one deploys an .msi file. It looks like a broader problem with GPO-driven installations on these machines. Any suggestions why some machines are rejecting the installs?
    Wednesday, March 25, 2015 6:03 PM
  • Hi criskrit,

    Some packages you deployed with GPO would not install untill you reboot the workstation. Would you please confirm if all the computers were rebooted after applied the group policy?

    Also if machine account for the workstation does not have permissions to the share or file system that holds the source files for the package could cause the workstations reject the installation.

    Please confirm that the machine account for the workstation that is applying Group Policy has at least Read access to the source files for the package that is assigned with Group Policy. You can do this by assigning permissions directly to the machine accounts, or by assigning permissions to a Security group, such as the Domain Computers or Authenticated Users group that contains the machine account.

    If the source files are located on a Distributed File System (DFS) share, confirm that the machine account has sufficient NTFS and share permissions on all root replicas of the DFS root, and on all replica shares of the DFS link.

    Best Regards,

    Elaine


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, March 26, 2015 2:15 AM
    Moderator
  • Hello Elaine, yes the machines have been  rebooted repeatedly. No luck. Permissions-wise "Authenticated Users" can access the shares, this doesn't seem to be an issue. We are not using DFS for this. -Christos

    Thursday, March 26, 2015 4:18 PM
  • Hi Christos,

    Hereby I provide some links that introduce some reasons can cause the group policy failed to apply.

    http://www.windowsnetworking.com/articles-tutorials/windows-server-2008/Top-10-Reasons-Why-Group-Policy-Fails-to-Apply-Part1.html

    http://www.windowsnetworking.com/articles-tutorials/windows-server-2008/Top-10-Reasons-Why-Group-Policy-Fails-to-Apply-Part2.html

    http://www.windowsnetworking.com/articles-tutorials/windows-server-2008/Top-10-Reasons-Why-Group-Policy-Fails-to-Apply-Part3.html

    They might give you some clue to troubleshoot the issue you encountered.

    Best Regards,

    Elaine


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, March 30, 2015 6:26 AM
    Moderator
  • Hello Elaine and thanks for the continuing help. I identified the problem. The GPO points to \\fileserver.domain.com\printer for the driver where "fileserver" is an alias. The above doesn't work. However if I use the actual server name (ie \\servername.domain.com\printer) or the IP address then it works. Why is this? It was working until 2-3 weeks ago and nothing changed. Is there a way to make it work for the alias? Thanks.

    Monday, March 30, 2015 1:05 PM
  • Just to summarize the problem:

    - Printer GPO doesn't work when pointing to \\alias.domain.com\printer but works when pointing to \\servername.domain.com\printer or \\ipaddress\printer. I have one GPO with 3 different printers, one for each setting and only the servername/ipaddress printers get deployed.

    - I have confirmed that DNS is fine, DCDIAG is clean, strict name checking is disabled on target server and ping/nslookup from the clients to the target alias works fine.

    - The problem happens only for some clients. So some client will get only the two printers while others will get all three. All clients are similar Win7 SP1 with all updates/patches.

    Given the last observation, is it possible that something on the client is causing this? ie the source location of the installer is an alias so the Install is rejected as unsafe or something. (just a thought).

    Thanks

    Christos

    Tuesday, March 31, 2015 2:56 AM
  • > - Printer GPO doesn't work when pointing to \\alias.domain.com\printer
    > but works when pointing to \\servername.domain.com\printer or
     
    Might be an issue that DisableStrictNameChecking=1 can resolve:
     
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Tuesday, March 31, 2015 9:22 AM
  • Hi Christos,

    Did you have a test according to Martin's suggestion?

    We'd like to hear the update from you.

    Best Regards,

    Elaine


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, April 02, 2015 3:18 AM
    Moderator
  • Hello Elaine,

    StrictNameChecking is already disabled and the server can be "manually" accessed using the alias ie I can use File Explorer to go to \\alias.domain.com. Everything was working until 3-4 weeks ago and it still works for some of the clients (but not for some others). If this is client-related what could be the reason? All the clients come from the same image.

    Thanks

    Christos

    Thursday, April 02, 2015 3:26 AM
  • Idea: Can this be an issue similar to the UNC warnings when opening an "unsafe" file? Just to make sure I added file://fileserver and file://fileserver.domain.com in the Intranet Zone. But this is a user-specific setting and the printers use a Computer GPO so not sure if it makes a difference.
    Thursday, April 02, 2015 5:43 AM