PrintBRM.exe, 0x80070043 and Print Clusters – A workaround

Since I’ve been working almost 24/7 over the holidays while migrating one huge environment (15.000 users) into a new one in a hurry. That is, without any previous knowledge of the old environment and a very tight schedule, I’ve been using all the shortcuts I can come up with. I quickly realised that PrintBRM would save my a*s when it came to migrating printers. I still ended up adding them more or less manually since I migrated from Windows Server 2003 x86 to a Windows Server 2008 x64-based cluster and the time finding the right drivers for it to work flawlessly would’ve been longer than the  manual add.

Anyway, once I’ve added all my printers to my new cluster I came to realize that I had screwed up in the cluster configuration so I needed to backup my printers and rearrange a little (I DON’T want to add those printers manually again). Along came PrintBRM.exe which I used to backup the old Windows Server 2003 server with from a Vista machine so I gladly fired it up on one of my cluster nodes. It came about 58% before it terminated with the good old error message “The following error occurred: 0x80070043. The network name cannot be found.” while backing up a driver. I removed the failing driver and tried again, 60% this time. I realized that I’d be deleting printers and drivers all night before it would finish so I needed a workaround.

I did some googling and came up with more people with similar problems:

And the usual how-to’s from Microsoft:;EN-US;938923

And if you bother to read any of the above you’ll quickly notice that there’s no solution. So I’ll give you my workaround:

I looked with process monitor since it was mentioned in the first forum post above, the error thrown is “Bad network name”. Let’s say our print server is called “PrintSrv”, and the syntax of PrintBRM is:


This will cause PrintBRM to go looking for PrintSrvc$WindowsSystem 32 to get the dll’s for certain drivers. A clustered print server doesn’t have a c$ since it only has a spooler, hence it’ll fail.

The solution

Check your Failover Cluster Manager for which disk is your print server storage (in the picture below it’s O:)


The following steps need to be done on the node that has the resources for obvious reasons:

Open Explorer and share your drive (regardless of letter, remember my O:) as C$


Open the drive in Explorer and create a directory called “Windows” (yes, that’s correct)

The below information is incorrect, I’ve now found the mklink.exe application included in Windows Server 2008 which will do the same as linkd.exe.

The syntax of the command is: mklink /D O:Windows C:Windows

Then you’ll need to download the Windows Server 2003 Resource Kit since you’ll be needing the linkd.exe application. This application creates junction points which in our case is just what we need.

If we assume that O: is our drive the syntax of linkd.exe will be: linkd O:Windows C:Windows

This will create a junction point (you can see this in explorer both on the arrow and the description) from O:Windows to C:Windows.

That’s it! Now you can backup all your printers regardless of driver.

Why it works? Well, we’ve shared our drive as c$ so now your clustered print server actually has a C$, and the junction point gives it ServerNameC$Windows and all the files PrintBRM is looking for are located there.

When you’re done you’ll need to remove the junction point: linkd O:Windows /D (D = Delete) and don’t forget to remove the sharing of your drive as C$ either.

This is filed as a bug with Microsoft so I’m hoping for a QFE / patch as soon as possible.

0 thoughts on “PrintBRM.exe, 0x80070043 and Print Clusters – A workaround”

  1. Thank you for this post. A few months ago I was pullling my hair out trying to migrate our 2003 Printer Server (part of a two node cluster) to a 2008 stand-alone print server and I couldn’t get the stupid PrimtBRM.exe to work for this exact reason. I would delete the printer it error’ed on, and it would continue a bit more. I had to abandoned our plans to migrate the printer server from the cluster because we simply just have to many, what I thought at the time, “imcompatable” printers. If you would, please keep my e-mail address handy on this issue and if Microsoft does put out a hotfix, let me know!

    With this new knowledge, I guess once again I will look at migrating our print server.

    1. Not a second too late then 🙂 The cluster team confirmed the issue, but QFE’s are quite quick these days. I agree, it’s just a printer!

  2. This site was helpful. I also posted this resolution that I found…

    Short recap follows:

    I have been chasing down an endpoint mapper issue for about a week when printbrm failed to install print queues. The error was:

    “Printbrm.exe (the Printer Migration Wizard or the command-line tool) failed to restore print queue C2620-PCL5E. The restore process will continue, skipping this queue. Error: 0x800706d9. There are no more endpoints available from the endpoint mapper.”

    I rebuilt three print servers thinking this was a configuration issue, chased down any rpc issue I could find, and quite frankly it was the windows firewall. I am using a third party firewall and when a print share is created it attempts to verify firewall setting using the Firewallapi.dll. So, I had to enable the windows firewall and run printbrm.exe again. (For you cluster users, you may also need to create a c$ share.) See this link for the firewall issue. See this link for print clusters. This worked for me. YMMV.

    John Wagner

Leave a Reply

Your email address will not be published. Required fields are marked *