Odpovědi

I had the same problem too. I finally solved it by sharing a Windows folder on Vista Box. Search for the ntprint.inf file on a Windows Vista Box. It will most likely reference windows\winsxs\x86_ntprint.infXXXXXXX. The WS08 server is looking for a x86 Vista Driver.

It seems that some third party printer driver .INF file is incorrect. Generally, Windows system tell the architecture (X86 or X64) of driver by reading .INF file of printer driver. If the architecture entry included in .INF file matches with system's, Windows system will install this driver.

For example, the following INF file includes an x64 driver is shown below:

1.[MANUFACTURER]

2.%Acme Corp% = Acme, NTamd64

3.[Acme.NTamd64]

4.%Acme Model% = Acme100PS, <hardware IDs>

5.[Acme100PS]

6.CopyFiles = Driver.DLL

The Model section is decorated with NTamd64, which indicates that this driver is an x64 driver. However, the Model decorations were optional for the earlier versions of Windows. For backward compatibility, these entries look like as following:

1.[MANUFACTURER]

2.%Acme Corp% = Acme

3.[Acme]

4.%Acme Model% = Acme100PS, <hardware IDs>

5.[Acme100PS]

6.CopyFiles = Driver.DLL

For some scenario, the printer driver couldn't be installed normally due to the incorrect format.For instance:

The additional driver can't be installed, because the .INF file is like this:

Generally, we can add a X86 driver on X64 Windows system by right-clicking printer driver to choose Properties, and clicking 'addition printer driver' to load a X86 driver. If this method doesn't work, we can try the method listed in my pervious reply. If these methods still couldn't work, I'd suggest contacting driver provider to ask a universal driver.

Všechny reakce

In order to add printer driver based on X86 on X64 system, please try the following steps to test the result:

1.On any one of the clients machine running 32-bit OS2.Access the print server \\PrintserverName\Printers3.Open the printer required to add the 32-bit driver4.Go to properties5.Sharing Tab6.Additional drivers7.check the box for x86 for windows 2000,windows xp and windows 20038.click ok

I hope this help.

If this issue still persists, please post back with latest error message.

I have the exact same problem and it is due to clicking the x86 box. It is asking for an ntprint.inf file and it refuses to use the one from windows 2003 server, windows 2003 R2 server & windows XP CD. There is also no associated file on the vista CD. Where is the file we need to support x86 print drivers on 2008 x64?

1.On any one of the clients machine running 32-bit OS2.Access the print server \\PrintserverName\Printers3.Open the printer required to add the 32-bit driver4.Go to properties5.Sharing Tab6.Additional drivers7.check the box for x86 for windows 2000,windows xp and windows 20038.click ok

I hope this help. If this issue still persists, please post back with latest error message.

Morgan

Is this the only supported way to do this? If so, it seems very strange that logic is built into the GUI to install both platforms, but only the local platform works.

The message I get is "Unable to install HP LaserJet 2420 PS, x86, Type 3 - User Mode driver. This operation is not supported."

Also, in my playing around with this server role, I have with verry little work managed to screw things up a couple of times now. Once my entire Vista32 driver catalog somehow got uploaded from my workstation, and just now when I connected via Remote Desktop a bunch of drivers got put on the server for my local printers.

How are we supposed to manage versions for multiple network printers? It seems that the driver database is fragile and there is no way to select a particular driver version for a printer. For example, the drivers tab seems to support multiple versions of a printer driver, however when I build a printer and select a driver, the version number is not included in the driver name.

I cheated and got it to work by exporting my printers from my 2003 R2 machine by commandline and importing them, now I can add 32-bit drivers with no problem. This is definitely NOT the way to do this, but at least it got me going again. M$ needs to get their collect head out of their butts and fix things like this.

It seems that some third party printer driver .INF file is incorrect. Generally, Windows system tell the architecture (X86 or X64) of driver by reading .INF file of printer driver. If the architecture entry included in .INF file matches with system's, Windows system will install this driver.

For example, the following INF file includes an x64 driver is shown below:

1.[MANUFACTURER]

2.%Acme Corp% = Acme, NTamd64

3.[Acme.NTamd64]

4.%Acme Model% = Acme100PS, <hardware IDs>

5.[Acme100PS]

6.CopyFiles = Driver.DLL

The Model section is decorated with NTamd64, which indicates that this driver is an x64 driver. However, the Model decorations were optional for the earlier versions of Windows. For backward compatibility, these entries look like as following:

1.[MANUFACTURER]

2.%Acme Corp% = Acme

3.[Acme]

4.%Acme Model% = Acme100PS, <hardware IDs>

5.[Acme100PS]

6.CopyFiles = Driver.DLL

For some scenario, the printer driver couldn't be installed normally due to the incorrect format.For instance:

The additional driver can't be installed, because the .INF file is like this:

Generally, we can add a X86 driver on X64 Windows system by right-clicking printer driver to choose Properties, and clicking 'addition printer driver' to load a X86 driver. If this method doesn't work, we can try the method listed in my pervious reply. If these methods still couldn't work, I'd suggest contacting driver provider to ask a universal driver.

I had the same problem too. I finally solved it by sharing a Windows folder on Vista Box. Search for the ntprint.inf file on a Windows Vista Box. It will most likely reference windows\winsxs\x86_ntprint.infXXXXXXX. The WS08 server is looking for a x86 Vista Driver.

I have tried this and was unable to make it work, I also tried to setup with a Vista 32bit system with the other work around once i check the box and close nothing happens, when i reopen it the check box is cleared. If i try to add it from a XP pro machine it promts me for drivers. ????

I had the availability of the Windows 2003 Server (32-bit) _Standard_ edition disc, put it in my wksta drive, administratively shared it and browsed to the file from the server. (I had tried R2, didn't work)

We implemented a 2008 Server (x64) and had nothing but issues with the HP Univeral Drivers, we also could not get the older standard drivers to work for our HP printers on the 2008 server. Our Dell printers worked fine.

I had the same problem too. I finally solved it by sharing a Windows folder on Vista Box. Search for the ntprint.inf file on a Windows Vista Box. It will most likely reference windows\winsxs\x86_ntprint.infXXXXXXX. The WS08 server is looking for a x86 Vista Driver.

Only some of the above worked for me at all, until, tearing my hair out, I actually found this clippit of information in a QMS printer driver for a combined x86 x64 driver package doing all Windows OS in a readme.txt - yes I was desperate!

1stly add the drivers using the print server properties drivers tab... I have selected both x64 and x86 at this point. Next add the drivers as it asks for them, x64 first on a x64 server... when it prompt for the x86 source provide it and then when it prompts for the ntprint.inf file, do the following...

"5. x86 additional drivers on Windows Vista x64: -------------------------------------------- To install an x86 additional driver on a Windows Vista x64 host, you first need a runningVista x86 system. On this x86 system, locate the directory\Windows\System32\DriverStore\FileRepository\ntprint.inf_xxxxx, then copy all files and sub-directories from ntprint.inf_xxxxx into the same location as you saved this driver.

If the x64 host asks for the NTPRINT.INF on the Windows Media during the installation of the additional driver, simply browse to this location and complete installation."

when you install the printers let the system scan as needed to work out what it wants and tell it to keep the existing driver (you added them earlier).when you share the printer, it will automatically have the x86 drivers box ticked and sorted and you just need to tick the box to show the printer in the list directory if you want to - this is under the printer's sharing tab.

Now all of my printers (HP, Brother and QMS) are all fine on my 2008 x64 box with x86 driversAdmittedly I have had to build a 32-bit vista machine, but I can at least go home now!

Wow, SBS is going to be 64 bit, isn't it? Is this being addressed on SBS 2008? This is certainly going to cause me to not deploy SBS 2008 at my clients if I have to deal with this everywhere. Or install a 32 bit VM to deal with it. But ____, SMBs are going to have to pay for a whole windows server license just to do print serving to avoid this cludge? I have a feeling SBS 2003 R2 is going to live on longer than MS intends just becuase of this cludge.

Nice Keswadmin and Bryant Fong (via sjarocki)! THANK YOU!I used a win2k8 x86 machine to copy these for a win2k8 x64 print share. Worked perfectly! Can't understand why the x64 win2k8 OS doesn't have this built in?????Thanks Again. I've been messing with this on and off for months (Dell 5110cn PS driver was the latest fubar).

Just an update to this in that for me, prior to step1 you need to share the printer out on the 64bit OS. Then for step 2 you probably just need \\PrintServerName then double click on the printer itself. Then you can go to the additional drivers and add the driver. In my case I had to do this for the Dell 2330dn printer.

While there are many work arounds and methods some of which are also listed here; I've found the BEST solution for installing printers on an x64 vista\2k8 system that will be hosting printers for x86 clients. Since the server is running a x64 OS, the x64 driver is required before you can create a new printer que. I decided to add the x86 and x64 drivers at the same time in the printer manager or print server properties. The driver versions must match!!! Also, when using this method I started out by downloading the latest Vista x64 and x86 drivers, even for a 2k8 print server and XP clients. The method below is using the Server Manager in 2k8 and assumes you have already obtained the required/matching drivers.

Open Server Manager Expand Print Servers > Server Name Right Click Drivers and select Manage Drivers... (at this point sill bring up the Print Server Properties window and the installed drivers will be listed.) Click Add... and then Next Check the box for x64 and x86 and click next Click Have Disk... and browse to the location where you stored the x64 driver and click ok Select the driver for the model you are installing and click next, then Finish. You will then be prompted for the x86 driver, browse to the location where you stored the x86 driver and click ok Select the SAME driver for the model you are installing and click ok.

You will be brought back to the Print Server Properties window and you can verify that the drivers have been installed on the server. Be sure to select the driver you just installed when adding the printer que to your server. Since the driver for the x64 and x86 versions are already installed on your server, both drivers will be installed as an additional driver on your printer que(s). I was NEVER prompted for the x86 NTPRINT.INF using this method.

"You will be brought back to the Print Server Properties window and you can verify that the drivers have been installed on the server. Be sure to select the driver you just installed when adding the printer que to your server. Since the driver for the x64 and x86 versions are already installed on your server, both drivers will be installed as an additional driver on your printer que(s). I was NEVER prompted for the x86 NTPRINT.INF using this method."

This all depends on the driver you are installing. If you are installing any old printers that don't have correctly coded drivers this won't work - you get the same issue as the people who posted above. For example, I followed your instructions to the letter to add the Post Script driver for a Xerox 8400 and received the NTPRINT.INF error.

From the 32 bit client machine which was adding the driver? To get the 32bit ntprint and files on the 64 bit server just add any inbox Windows 7 32bit driver onto the 64 bit machine using the 32bit machine. Once the 32bit package has been installed on the 63bit server you should not be prompted for this file set again.Alan Morris
Windows Printing Team;
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/search/Default.aspx?adv=1

I am having an issue like this as well, unfortunately I don't have any 32 bit Vista or Windows 7 machines on the network, I am using a 64 bit 2008 server R2 machine as my print server and I too am pulling my hair out trying to figure out how to get the x86 drivers installed. At first I was getting the type 3 mode error on the server which meant that I have to install it from a client. When I try and install it from the client I am not even given a chance to put the driver in, it immediately says no suitable driver is available. I would love to have some asstance on this one, thanks!!!

Are all your 32bit clients XP and Server 2003? You can use them to install the driver to the server but you can't open the properties of the printer since you do not have the driver installed on the client. Install the driver on the client first or just ignore the driver install prompt and get the properties UI open to the point where you can click the Additional Drivers button on the sharing tab. Alan Morris
Windows Printing Team;
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/search/Default.aspx?adv=1

STEP BY STEP GUIDE TO GET A WORKING NTPRINT FOLDER FROM WINDOWS 7 MEDIA.

If you have a Windows 7 32-bit CD, perhaps with a new computer, OEM disc should work fine, do the following:

1. Make a folder on your C Drive called Win7Mount 2. Obtain a copy of ImageX. This can be downloaded from Microsoft. It is their new imaging software. 3. Insert your Windows 7 DVD or mount your ISO. Note the drive letter. 4. Open a command prompt and change directories to wherever ImageX is installed. I have the Windows AIK installed so mine was at C:\Program Files\AIK\Tools\x86. 5. Type the following command: imagex /mount H:\Sources\install.wim 1 C:\Win7Mount and press ENTER. 6. Wait for imagex to complete. Will take 2-3 minutes to fully mount DVD. 7. Now browse to C:\Win7Mount\Windows\winsxs\ 8. Copy the contents of x86_ntprint.inf_31bfxxxxxxxxxxxxxxxxxxxxxxx to wherever you save your Print Drivers. I called it "Windows 7 32-bit NTPRINT". That way when I need it in the future I will remember what it was for. (Note: there is another folder called x86_ntprint.inf.resources_xxxxxxxxxxxxxxxxxx. I copied the contents of that one as well, but didn't need it. I figured I might in the future so I went ahead and grabbed it now.) 9. Now type: imagex /unmount C:\Win7Mount and press ENTER. This process will take 60 seconds or so. 10. Now when the print server asks for the Windows media, just browse to that new folder you created and it will find the files needed.

Thanks for KESWADMIN and BRYANT FONG for the winsxs help. I just thought I would put all the steps together for people that might not have it installed, but do have the media available.

I have this scenario my printer server is windows 2008 standard edition x86 i successfully add the x64 driver on my server but when i try to access shared printer installed on my 2k8 x86 server on my windows 7 Enterprise x64 no driver is available. any idea on what should i do?

The print driver names do not match, you will need to find matching drivers for Point and Print to work properly. PCL6 does NOT equal PCL 6. When using Global and Universal drivers you need to install both x86 and x64.

Thanks for all of the infomation on this one. I would like to add one extra thing ...

We need to programatically add printer drivers to servers as part of the build process and to update servers for updated printers. We will have about 800 servers to maintain, so installing the 32 bit driver using a 32 bit client is out of the question.

We have tried 2 methods to install the printers, PowerShell and rundll32. PowerShell is the prefered method, however it still doesn't behave the way we want.

I have a pretty good solution, and it seems to work great! At least now for HP drivers, I just have to get some more data collected for other drivers... unless someone can point me to the definitive location of the name of a printer in a INF, i have a nice script that takes a specified folder where you place a seperate folder for each driver set. It will parse every single inf, and determine what mode to install it in and what to name it.

As stated above, I mounted the VISTA WIM file and took the WSXS x86_NT.PRINTXXXXXXX folder and copied it to a shared area and added it to the SourcePath in the afore mentioned setup key. After one install, it has never prompted me again for it. (I also removed everything else in it temporarily) Oh and as usual BACK THE KEY UP as they always say.

50 Printer drivers, minus the time to download them, installed in 3 minutes. Now as far as migrating from 2k3 to 2k8, still working that issue... they say right click, i don't think they ever tried it. I am seriously guessing that you may need that hop box, but please anyone tell me you have done it w/o the vista hop, keeping ports/names/shares the same, i don't care about the server name. I am going from 5 single servers to a 6 node 2k8 cluster with 3 print resources ;) Ug... I'll post the script soon. I want to touch it up a bit, and get some other brands and see how they identify the driver name in the INF file. If there are any INF gurus out there here is what I am looking for:

As far as identifying strings i am looking for, I just know that the HP INF file has a [strings.xxxx] section which lists:

HP_Mombi_Driver_Name = "HP LaserJet 4250 PCL 5e"

and it will use that during the call to the printUI interface.

It's almost pretty, there are a few gotchas still I can post a 'beta' if anyone wants to see it, give me a day or so and it will be final. I have over 3000 printer to migrate. Feds want a printer in every cube, go figure. j/k just a big environment.

That fixes it, we had automated it using scripts, but we were still getting a pop up box for the first 32bit printer driver installed on the server (which we used a script to acknowledge). We are now using the following process to automatically install 64 bit and 32 bit drivers on a server as part of the build process (the print queues are setup later).

Run rundll32 printui.dll,PrintUIEntry command to install 64 bit version of each printer driver

Copy ntprint.inf from a 32 bit version of Server 2008 to a local location

Run rundll32 printui.dll,PrintUIEntry command to install32 bit version of each printer driver with the /F switch pointing to the 32 bit version of ntprint.inf

I ran across a similar problem installing the Xerox Global Printer on a 2008 x86 print server. The x86 driver installed with no issues, but the x64 version asked for ntprint.inf. I followed the suggestions above, but was not able to find a version
of ntprint.inf that made it succeed. I tried Vista x86, Vista x64, 2008 x86, 2008 x64, and Windows 7 x86 and x64.

I finally got it working by following this procedure. I'm not sure why it worked, but it's worth a go.

1. Installed the x64 driver (the problem one) on an x64 version of Windows 7. This installed without issue.

2. Copied the DriverStore folder that it created to the print server (in my case for the Xerox driver: C:\Windows\System32\DriverStore\FileRepository\x2univl.inf_amd64_neutral_e51bcd78a4d30f67). Note that it's under System32 even though I'm doing this
on an x64 Windows 7 workstation.

3. Imported the driver on the print server from the INF file in this copied folder. This succeeded and did not ask for ntprint.inf this time.

For some reason that sequence of events worked for me and I'm not able to deploy both x86 and x64 Xerox printers from my 2008 x86 print server.

it worked for me I copied the folder "x86_ntprint.inf_31bf3856ad364e35_6.1.7600.16385_none_3ad6f3251c0676a9" from my windows 7 porf. PC and worked like magic on my server 2008 R2 when installing HP office Jet Pro 7580.

I've got HP printers (2300, 2420, 4200, 4250, 4350). All the clients on the network running on windows xp pro sp3. Couple of days ago did transition from server 2003 enterprise to server 2008 R2. All things moved. Just need to move anti-virus and printers.
Printers giving me an issue. The clients using XP when trying to add the printer get asked for a driver - what is the solution? Thanks in advance!

Are you using the 64bit version of the print driver that has the same name as the 32bit version. The 64bit print server is using a different driver if you migrated a 32bit server to 64bit. In order for the XP machines to sync up properly, a 32bit
version using the same name as the 64bit version needs to be installed on the print server. PCL6 does NOT equal PCL 6 so watch for spaces in the name.

What is the error message? From the inf files for the driver, what is the 64bit driver name? What is the 32bit driver name?

If you just need the ntprint portion of setup start by adding any 32bit driver included in Windows 7 or Vista remotely to the server. Then try to add the vendor driver that does not include the core driver files.

How to add support for printing from 32bit clients to a Windows Server 2008 R2 print server

Having read through this lengthy topic I thought I would
summarise how to solve the original question asked by TJ Cornish.

The problem occurs when you are trying to install 32bit (x86) PCL or PS printer drivers that are based on the Microsoft mini print driver on a 64bit (amd64) Windows server.The Kyocera Universal Classic driver is an example of a driver based on the Microsoft mini print driver.Drivers not based on the Microsoft mini print driver such as HP Universal Print Driver for Windows or Ricoh Driver for Universal Print do not have this problem.You can tell if the driver you are trying to install is based on the Microsoft mini print driver, by searching for ntprint.inf in the drivers inf file.

When trying to install such a 32bit printer driver on Windows Server 2008 R2 (which is 64bit only and shares the same code base as Windows 7) I got the following message
asking for ntprint.inf

Install Components from Windows media

Please provide path to Windows media (x86 processor)

The best solution provided above is by R_Farquhar, who details how to extract the 32bit version of the Microsoft Print driver (ntprint) from a Windows 7 DVD or ISO using
ImageX. You could also copy the driver from a 32bit Windows 7 PC (if you have one) as suggested by Bryant Fong and Keswadmin.
You will only be asked to locate ntprint.inf for the first 32bit driver you install, any drivers you install after that will use the already installed driver.

So far, a clean upgrade path from x86 2003 to x64 2008 R2 has not been revealed. The intention in my scenario is to be able to have the end users retain all their printer settings, not have to switch all my printers to the HP universal driver or other
type items.

The end all question:

Is there any possibilty to migrate the existing printers on a 2003 box to a 2008 r2 box w/o converting every printer to the x64 bit drivers and having to recreate every queue / port etc...

I am like days away from starting my production builds, ( AFTER i replace every single system board on my dl380s cuz the random reboot), and want to know what to plan for. ;)

It will depend on the drivers. If you use print drivers included in 2003 and have added the matching x64 drivers from 2003, this does work. Most HP drivers contain private devmode (device mode) information and it is the responsibility
of the new driver to take the previous private devmode and convert to a new devmode. HP typically has structures in the old devmode that do not match with the new devmode structures and suggest creating a new printer that uses the
new driver (creating the new devmode structure at this time) rather than attempting to upgrade the old devmode information to the new driver. I'd say 100% of the vendor driver contain a private devmode section, the size of this devmode and how it is
handled by the driver is the main issue. The demode requires upgrading either both x86 to x64 and OS to newer OS migration.

Yes, I know, the drivers in 2003 are 7 years old and the printers you use in production are a bit newer so this does not work either.

I assume you have already reviewed the migration guide and the printbrm information on technet ASKPERF

If you currently have 2008 R2 installed but not in production, I suggest migrating to a physical of VM machine first. If you have HP drivers and and are replacing with Universal, I'm pretty sure the spooler process memory will get corrupted during
the devmode conversion and terminal. Turning on print driver isolation will assist in that the spooler will not terminate.

Restore to the temporary machine. Add missing drivers or modify the brmconfig.xml to use a different driver and restore again selecting to retain existing printer. When you have the x64 machine setup as a mirror of the 32bit printer server, backup
the machine. This is the file you will use to restore to your new print server.

What you have 25 print servers? Now that you have the backup (I'd actually confirm the backup works on a clean install), delete the printers and ports from the temporary machine. Don't delete the print drivers, you spent too much time adding
them. Now backup your other print servers. You can use the -NOBIN option if all the print drivers you need are already installed on the temporary server, then restore to the temp server and make the backup for SERVER2.

If any of the backups fail (error 2) after the driver backup portion, there is a language monitor that has been removed from the registry but one of the print drivers still references it and the solution is in a different post.

The only clean upgrade path depends on installing drivers that do not contain large or complex private devmode structures that also have a matching named x64 version.

I'd love to have a solution for you but the group that releases the product would never let the alternate processor files (ia64 and x86) on the DVD. The last time cross platform print drivers for the same OS were included on the CD was for
NT4.

just started setting up a print server on a new 2008 R2 machine and ran into the same issues as most other folks did. When I tried to add additional drivers (x86 drivers
in this case) it would give me the common: Install Components from Windows media
Please provide path to Windows media (x86 processor). This occurs with some x86 drivers and not all.

The response by
Duncan Clay was right on target and worked very well. We are an XP workshop but I am running Win 7 32bit (cause I need to for supporting and testing with our users) and what
I did was Share out my Windows\winsxs folder where I found the
ntprint.inf file and pointed the Server to the
x86_ntprint.inf_xxxxxx folder and it loaded it from there.

All works now and if there were any other drivers that would have had the same issue - they work now.

It was easier for me to setup a new print server with 50 printers then to upgrade my old 2003 sp1 machine
to sp2 then load all the 64bit drivers on it before migrating over to the new system. If I had 100's of printers then yes.

It will depend on the drivers. If you use print drivers included in 2003 and have added the matching x64 drivers from 2003, this does work. Most HP drivers contain private devmode (device mode) information and it is the responsibility
of the new driver to take the previous private devmode and convert to a new devmode. HP typically has structures in the old devmode that do not match with the new devmode structures and suggest creating a new printer that uses the
new driver (creating the new devmode structure at this time) rather than attempting to upgrade the old devmode information to the new driver. I'd say 100% of the vendor driver contain a private devmode section, the size of this devmode and how it is
handled by the driver is the main issue. The demode requires upgrading either both x86 to x64 and OS to newer OS migration.

Yes, I know, the drivers in 2003 are 7 years old and the printers you use in production are a bit newer so this does not work either.

I assume you have already reviewed the migration guide and the printbrm information on technet ASKPERF

If you currently have 2008 R2 installed but not in production, I suggest migrating to a physical of VM machine first. If you have HP drivers and and are replacing with Universal, I'm pretty sure the spooler process memory will get corrupted during
the devmode conversion and terminal. Turning on print driver isolation will assist in that the spooler will not terminate.

Restore to the temporary machine. Add missing drivers or modify the brmconfig.xml to use a different driver and restore again selecting to retain existing printer. When you have the x64 machine setup as a mirror of the 32bit printer server, backup
the machine. This is the file you will use to restore to your new print server.

What you have 25 print servers? Now that you have the backup (I'd actually confirm the backup works on a clean install), delete the printers and ports from the temporary machine. Don't delete the print drivers, you spent too much time adding
them. Now backup your other print servers. You can use the -NOBIN option if all the print drivers you need are already installed on the temporary server, then restore to the temp server and make the backup for SERVER2.

If any of the backups fail (error 2) after the driver backup portion, there is a language monitor that has been removed from the registry but one of the print drivers still references it and the solution is in a different post.

The only clean upgrade path depends on installing drivers that do not contain large or complex private devmode structures that also have a matching named x64 version.

I have noticed that many of the posts in this thread reference issues with drivers which are WHQL Certified, yet still require a crowbar, a script, Ducktape, and a can of WD-40 in order to get these to work correctly when installed on MS Server 2008.

As Server 2008 x64 is the Premier product offered, and Windows Hardware Quality Laboratory charges these manufacturers for certification, one must wonder why the defensive posture in the official MS Answerer replies?

I see your approach for cross-platform driver model as being flawed.

That said, the ntprint.inf_xxxxxxx can also be found by downloading the Windows AIK, burning the DVD from the ISO, and browsing to the folder containing said file.

It seems to me that if it was known that 64 bit and 32 bit drivers would require different versions of the ntprint.inf file when 2008 was released that they would have been provided on the OS media. This is exactly the sort of poor planning and failure
to pay attention to detail that I have been growing numb to for 15 years.

REALITY: Companies migrate in phases. There WILL be a mix of architecture in most environments.

CURRENT SOLUTION: Gather files from the wrong OS media to make the chosen OS function correctly.

CORRECT SOLUTION: Include the required file in a patch and end this thread forever.

I am working on an entrprise migration from x86 virtual print servers (1 proc/2 gb ram) to x64 physical monsters (4 proc / 4 core 16 gb ram). As far as i am concerned about the HP drivers, i have found over 95% of the printers are now on the HP
UPD v5.11 which has just been recently released. I am very happy with the fixes they have implemented and it is now very responsive to all printers in the properties and preferences pages.

For the other printers, that do not have the x64 / x86 upd available, i have found older x64 and x86 drivers. I have moved 1100 printers from 32bit microsoft / HP drivers to the UPD and will be piloting here in the next month to mulitple components
in our agency. I expect to have pretty good success, but I am finding out from my own research that the current operations team may have used HP drivers on some xerox and lexmark printers. So i am writing a vbapp to poll each port listed on the
production print servers and query the model from the printer itself for verification.

I have been living this nightmare for about 9 months now, but the release of the HP UPD v5.11 has wiped most if not all my worries away.

Most of the solutions involve copying x86 architecture-specific files to an x64 operating system in some fashion. If I do this for my Windows Server 2008 R2 print server, what happens when Windows Server 2008 R2 Service Pack 1 is released? I'm
assuming it won't update these x86-specific files. Best case everything still works, but I don't get any SP1 fixes for these x86-specific files? Worst case something breaks somehow because the x86-specific files are still SP0 and the rest of the
system is SP1?

Most of the solutions involve copying x86 architecture-specific files to an x64 operating system in some fashion. If I do this for my Windows Server 2008 R2 print server, what happens when Windows Server 2008 R2 Service Pack 1 is released? I'm
assuming it won't update these x86-specific files. Best case everything still works, but I don't get any SP1 fixes for these x86-specific files? Worst case something breaks somehow because the x86-specific files are still SP0 and the rest of the
system is SP1?

Mark

This is correct for print drivers

"I'm assuming it won't update these x86-specific files. Best case everything still works, but I don't get any SP1 fixes for these x86-specific files?"

Nothing has changed for 2008 R2 to provide 32bit core print drivers with the SP.

Just installed the beta SP on the nodes of my print cluster yesterday. The 32bit files included in the OS, the ones in SYSWOW64, do get updated

I've been reading through this thread with increasing irritation. We shouldn't be having these problems and shouldn't be putting up with the ugly work-arounds offered here.

This is basic stuff. How did it go so badly wrong?

Our 64 bit server deployment is waiting for 32 bit drivers and I'm frustrated and amazed at how badly this whole area hangs together (or doesn't).

I get to the point where I'm asked for the E:\i386 media and give it a CD which contains what it tells me it wants. All it does is re-prompt me for the same file. No error message. No clue as to what it wants or why this file is no good.

So I'm reduced to unpicking the ugly fudges above in the hope that one works for me.

I have also been reading into this issue. Alot of good suggestions. Here is mine. (PS requires an administrative level account)

Here is an easy solution to try for those who have to setup the server as a print server. These steps assume you have the 64 bit version of the driver already setup on your server, but you are having issues installing the 32 bit version.

1. Install the driver on a standard 32 bit client. Save the driver folder for step 3. (I used Win7) (This gets the 32 drivers and correct ntprint.inf into the local computers driver cache).

2. Then install the shared printer from the print server on that same 32 bit client using standard methods (like START, RUN, \\servername, then double clicking the printer).

3. It may ask you about locating the driver (point it to the driver folder you saved), or it may just install.

4. Now for the trick to push that driver up to the server..... Right click the shared version of the printer, and on the SHARING TAB, click "Additional driver". You will find the x86 driver unchecked. Check it and the local 32 bit client will copy
the local driver and ntprint.inf up to the server for you.

I had a simulair issue, but with 64-bits Windows7 drivers to add on a 32-bits Windows 2008 printserver.
On these printservers we have al kind of 32-bit Windows XP drivers, and we wanted to add the 64-bits driver additional, remember first to have the same version number for the 32 bits aswell as the 64 bits driver

I installed some familydrivers from OCE and it asked for ntprint.inf aswell, the answer from OCE was quite simple:
Install the driver from a CLIENT, I did this but no driver appearred on the server, then on the client I opened printer properties - TAB: Shares and hit the Additional drivers... button, then selected the 64 bits driver and the client uploaded the driver to
the printserver.

In print management on the printserver there was added the 64-bits driver from the client, now when I add the same printer on an other client it recieved the correct 64-bits driver but now from the server.

Hope this works the same as the original start of this topic with 32-bits driver on a 2008 64 bits server.

STEP BY STEP GUIDE TO GET A WORKING NTPRINT FOLDER FROM WINDOWS 7 MEDIA.

If you have a Windows 7 32-bit CD, perhaps with a new computer, OEM disc should work fine, do the following:

1. Make a folder on your C Drive called Win7Mount
2. Obtain a copy of ImageX. This can be downloaded from Microsoft. It is their new imaging software.
3. Insert your Windows 7 DVD or mount your ISO. Note the drive letter.
4. Open a command prompt and change directories to wherever ImageX is installed. I have the Windows AIK installed so mine was at C:\Program Files\AIK\Tools\x86.
5. Type the following command: imagex /mount H:\Sources\install.wim 1 C:\Win7Mount and press ENTER.
6. Wait for imagex to complete. Will take 2-3 minutes to fully mount DVD.
7. Now browse to C:\Win7Mount\Windows\winsxs\
8. Copy the contents of x86_ntprint.inf_31bfxxxxxxxxxxxxxxxxxxxxxxx to wherever you save your Print Drivers. I called it "Windows 7 32-bit NTPRINT". That way when I need it in the future I will remember what it was for. (Note: there is another folder called
x86_ntprint.inf.resources_xxxxxxxxxxxxxxxxxx. I copied the contents of that one as well, but didn't need it. I figured I might in the future so I went ahead and grabbed it now.)
9. Now type: imagex /unmount C:\Win7Mount and press ENTER. This process will take 60 seconds or so.
10. Now when the print server asks for the Windows media, just browse to that new folder you created and it will find the files needed.

Thanks for KESWADMIN and BRYANT FONG for the winsxs help. I just thought I would put all the steps together for people that might not have it installed, but do have the media available.

this finally worked for me, however i use 7zip and was able to browse my iso then the wim file within easy and drag and drop the x86_nt folder into my home drive for easy pointing, thanks!!-tommy

Only some of the above worked for me at all, until, tearing my hair out, I actually found this clippit of information in a QMS printer driver for a combined x86 x64 driver package doing all Windows OS in a readme.txt - yes I was desperate!

1stly add the drivers using the print server properties drivers tab... I have selected both x64 and x86 at this point.
Next add the drivers as it asks for them, x64 first on a x64 server...
when it prompt for the x86 source provide it and then when it prompts for the ntprint.inf file, do the following...

"5. x86 additional drivers on Windows Vista x64:
--------------------------------------------
To install an x86 additional driver on a Windows Vista x64 host, you first
need a runningVista x86 system. On this x86 system, locate the directory\Windows\System32\DriverStore\FileRepository\ntprint.inf_xxxxx, then copy
all files and sub-directories from ntprint.inf_xxxxx into the same location
as you saved this driver.

If the x64 host asks for the NTPRINT.INF on the Windows Media during the
installation of the additional driver, simply browse to this location and
complete installation."

when you install the printers let the system scan as needed to work out what it wants and tell it to keep the existing driver (you added them earlier).
when you share the printer, it will automatically have the x86 drivers box ticked and sorted and you just need to tick the box to show the printer in the list directory if you want to - this is under the printer's sharing tab.

Now all of my printers (HP, Brother and QMS) are all fine on my 2008 x64 box with x86 drivers
Admittedly I have had to build a 32-bit vista machine, but I can at least go home now!

I was struggling with this last week. For me, by far the quickest solution was to use the global drivers provided by Xerox. Go to their drivers page and download the 64-bit PCL and PS global drivers, then download the 32-bit versions. The downloads include
the drivers plus the correct ntprint.inf everyone's looking for. No digging around cab files, no looking for installation media, no playing with pnputil, etc. It just works. You install the 64-bit version, then you install the 32-bit version, and point it
to the x86 ntprint.inf included with the download.

yes, just get right driver then it should be ok, but we still have one problem, with Xerox DC 450I printer, for X64 PC, it can print double size; but for x86 PC, double size option can't be choosen. Any clues?

I was struggling with this last week. For me, by far the quickest solution was to use the global drivers provided by Xerox. Go to their drivers page and download the 64-bit PCL and PS global drivers, then download the 32-bit versions. The downloads
include the drivers plus the correct ntprint.inf everyone's looking for. No digging around cab files, no looking for installation media, no playing with pnputil, etc. It just works. You install the 64-bit version, then you install the 32-bit version, and point
it to the x86 ntprint.inf included with the download.

This is exactly how I was doing it however sometimes there is not a X64 driver which is what brought me to this thread in the first place. The ntprint cab will get you around the issue of installing a X86 only driver on and X64 print server.

i just discovered an easy way to do this. I installed all the 32 bit MS Print inbox drivers on a Win 7 32 bit machine and used printbrm to back it up, then restored that to a x64 r2 server. During the restore and for a short while after, the
x64 server installed the matching x64 bit drivers. Suprised me, i was getting read to install the 64bit counterparts when i saw them poplutating already.

This was only for microsoft drivers. Not sure how the others would work. But for my 32 to 64 solution, i am staging all the drivers on a 32 bit w7 enterprise machine, backing that up, restoring to 64bit 2008 r2 server, adding the missing 64 bit
drivers, backing that up and then to a cluster. I am trying now to do this with out the UPDs due to their lack of good.

I was struggling with this last week. For me, by far the quickest solution was to use the global drivers provided by Xerox. Go to their drivers page and download the 64-bit PCL and PS global drivers, then download the 32-bit versions. The downloads
include the drivers plus the correct ntprint.inf everyone's looking for. No digging around cab files, no looking for installation media, no playing with pnputil, etc. It just works. You install the 64-bit version, then you install the 32-bit version, and point
it to the x86 ntprint.inf included with the download.

Perfect! And I don't even need the Xerox drivers. I installed them, got the ntprint.inf that was needed taken care of, installed the other x86 drivers I needed, then removed the Xerox drivers. More steps that entirely necessary, but a heck of a lot easier than
some of the other suggested answers.

Thanks to everyone who came up with work-arounds. We're just about to move to a Win2008 R2 print server and adding the additional 32bit drivers had become a nightmare. We have a mixture of HP, Konica and Oce printers, all of which gave us the same ntprint.inf
issue.

t0mmyr's suggestion worked well for us:

- Its very simple... get your hands on a 32bit version of Vista, Win 7 32bit or Win 2008. Either the setup CD/DVD or .iso file will work fine.

- Using 7zip (it's free to download) browse to the following folder on the setup CD or .iso file: sources\install.wim\1\Windows\winsxs\

- Copy the x86_ntprint.inf_31xxxxxxx folder to a network share or to a local disk on your 64bit print server.

- Now add the additional 32bit print driver as normal, when Windows prompts for ntprint.inf just navigate to the folder you've just copied.

I had the exact same problem described by TJ Cornish, and was able to resolve it fine using the method described by Bryant Fong. I used a Windows 7 32-bit version. This driver is now installed on my 2008R2 and 320bit clients are pciking up the driver and
using it successfully.

BTW: Tried to cheat and get the x86_ntprint file from an older 32bit version of Server08....no go.

Just spun up a quick VM of Vista 32bit business edition using VirtualBox, shared the windows\winsxs\x86_ntprint.inf_xxxx folder pointed to it from my 64bit Server08 print server and it went like a champ.

If this issue still persists, please post back with latest error message.

Morgan

This worked a treat thanks. Easiest solution here. Obviously you will need to be logged on as someone with local admin on both Servers. I was and it worked so props to you thanks.

I want to think the person that posted the above solution. I had 7 printers to setup and this worked for 4 of them. I still had a problem with 3 HP printers.

Not that it matters, but they were an HP4000N, HP4100N, and HP4050. The problem was that when I first installed these on the Windows 2008 64 Bit server, it grabbed drivers from MS. That wouldn't be a big deal, if when I went to share them it
would have searched MS for the 32 bit versions. Some where in this thread, there are many references to using your Windows 32 bit client CAB files and that probably works too, but here is what I did and it fixed the issue.

1) I DL'ed from HP their 64 bit and 32 Bit Universal Print Driver PCL5 and PCL6 files (I could probably have used one or the other, but I had historically done PCL5 on the HP4000 and 4050 and PCL6 on the 4100.)

2) I unzipped these onto our file server's software share so I could access them from any machine.

3) I updated the 64 bit driver for the printer to be the 64 bit version of the HP Universal print driver.

4) Once the printer was using that 64 bit driver, then when I went into the sharing properties and selected load additional drivers an choose that I wanted to load a 32 bit driver, I pointed the file location dialog box to the 32 bit HP Universal Driver
I had DL'ed in step 1.

This made sure that the Server was using the 'EXACT' same driver for both 32 bit and 64 bit.

It really wasn't hard, but took about 6 hours of reading various forums to come up with it. I don't know if that will fix everyone's problem or not, but it's worth a shot.

If I was doing this for a Non-HP printer, I would just go to that printer's web site and make sure I got their latest 64 bit and 32 bit driver for that printer (providing of course they have one of each).

This work which is interesting because at this stage of the game we should not be going through these problems. XP (x86) was there before the 64 bit and Dell and HP should have a solution for these problems. HP did came out with a Universal driver that do
work especially for the 4000 series printers. Dell on the other hand needs to catch up to speed. Thanks to all who labor daily to make our lives easier find the correct methods to solve a problem here or there.

This work:

Go the an XP (x86 machine and follow the notes below). One thing that is not mention here is you have to copy the driver file down to the PC (xp) machine before you get started. For example the Dell 5210n printer copy the X86 drivers you were trying to install
on the 64bit windows 2008 server.

Do this:

Down this file it is the windows 2008 32bit (x86) drivers for the Dell 5210n

R210852.exe (13MB) (32/ x86bit)

Down this file it is the windows 2008 64 bit drivers for the Dell 5210n

R210906.exe (4MB)

Run the R210906.exe first for the server to get the printer up and running on the server.

Then copy the r210852.exe to the client PC (xp) and extract the file driver.

Then follow below to complet the install.

It works! thanks Morgan!

Mark /

In order to add printer driver based on X86 on X64 system, please try the following steps to test the result:

Keswadmin, I'm glad you're around. It took me up to your post to find the right solution to be able to install a X86 printer driver on our win2k8r2 x64 machine (acting as a printer server). It worked like a charm! Thanks again.

- Connect to printer from Win7 32-bit machine, eventually it will ask you if you want to browse for the 32-bit driver...click yes and browse to your folder with the 32-bit drivers.

- Now go into printer properties on the Win7 box and click on the sharing tab

- Open additional drivers and check the x86 box

This will copy the needed files from your local Win7 32-bit box up to the 64-bit server and enable the x86 driver.....Now the print server has both the 64-bit and 32-bit drivers installed for when a client connects to the printer.

It is always the same problem: Missing NTPRINT.INF - caused of missing files because of MIX-Bit-Installation - I had this problem in different environments, solution was always WIN+R, "printmanagement.msc"

You can use this information on 32 bit printservers or 64 bit printservers - just vice versa.

If you have a 32 bit OS as server:
1.) organize Printerdriver of same Version and PDL - store and extract them if neccessary
2.) install the printerobject (queue) with the 32 bit drivers on 32 bit server
3.) on a newer 64 bit OS (best to use that OS what is a typical client OS in your environment) open Start, run, "printmanagement.msc", right-click printserver and then add your 32 bit printserver (best if they are in same domain..) - if can't connect
properly try to map any share of this host before doing this after a fresh reboot.
4.) expand drivers, right-click add driver and install the same driver as in "1.)" downloaded to your 32 bit host in 64 bit version - now missing NTPRINT.inf is pumped to your 32 bit Host.
5.) switch to your 32 bit host - go to the "share-tab" of your queue you installed in "2.)" - click "other drivers" - if not yet checked x64 you have to check it and try to install 64 bit driver again - this should work now without
question of NTPRINT.inf as you pumped it over in step "4.)"

If you have it the other way round (64 bit server, 32 bit client) - just do it vice versa..

If this issue still persists, please post back with latest error message.

Morgan

To add x86 drivers to x64 2003 Server the only way seems to be is similar to this. Also this works if you have no shared printers, only drivers for terminal printing. Here it is:

1) Add any printer that is managed by you remotely e.g. in RDP session, x64 server will copy your x64 drivers. Now you can see remote RDP printers and your one by opening
\\2003x64servname\printers or similar way. And best of this is that you will be able to set print server properties, where you can add x86 drivers remotely.

2) Login with your account (the same that was used to share printer installed in 1.) on Win XP x86. Open path
\\2003x64servname\printers in explorer. Right mouse click - Print server properties

3) Add driver here for x86. Now it will be added without ntprint.inf prompt. Check - the x86 printer driver on x64 2003 Server (I used R2) is now installed.

Try this on 2012 server when trying to add a 32bit driver with the old print server still in service:

On old 2003 server, browse to C:\windows\system32 and share the DRVSTORE folder.

From the new server after selecting x86 driver check box and it asks for your files, point it to \\<oldserver>\DRVSTORE share you just created. You may have to poke down through a couple of folders to find the right one. Worked like a charm
on our recent upgrade.