Local Printing problems w/ Active Directory

BigTone

We are currently rolling out Active Directory in a dozen or so remote offices around the country. The first office we installed on everything went smoothly, except for one thing. Local Printing from a web application.

We are using a web app on a web server in the domain to print a check to a desktop computer with a local printer.

The web server was in a workgroup and it wasn't working so we moved it to the domain and it is still having issues. It doesn't get past the Printing- Spooling part if we try a test page.

Anyone have any suggestions? This is a mild problem at the moment because they can export checks to adobe and print them, however some of our remote offices have like 15 okidata printers all connected locally (don't ask) and its going to become a bigger issue.

hetty

Driver issue?

BigTone

shouldn't be, it has the PCL 5e driver...

hetty

The document is spooling to the locally attached printer and port (LPT, USB, TCP?) rather than a printer on the web server yaeh?

Deleting it and adding it again doesnt sort it? Maybe try the PCL 6 driver.

BigTone

hetty wrote:

The document is spooling to the locally attached printer and port (LPT, USB, TCP?) rather than a printer on the web server yaeh?

Deleting it and adding it again doesnt sort it? Maybe try the PCL 6 driver.

No, like a test page from the web server to the local printer just sits there and shows it spooling, I don't even think it makes it to the local printer.

Claymoore

Is the web server running an application that is trying to print to a workstation printer or does the web app render the doc in the browser and the user is trying to print to a locally attached workstation printer? I'm trying to understand which computer is attempting to print and to which computer the printer is attached.

BigTone

Its a web app that sends the document to the local printer via the web server.

On the user end the user selects an option (export to PDF, print)

Then the user Bigtone selects a printer, bigtone hp laserjet and clicks print.

Claymoore

Check and make sure that the service account under which the web app is running has rights to print to the shared workstation printers. For that matter, make sure the printers are actually shared...

BigTone

Claymoore wrote:

Check and make sure that the service account under which the web app is running has rights to print to the shared workstation printers. For that matter, make sure the printers are actually shared...

Not to sound completely dumb, but what service account would it be? Aspnet? I looked but I didn't even see it in the directory...

BigTone

Printers aren't shared... I'm not sure if they need to be at the current time. They didn't have to be in our old NT domain. Not unless they were sharing printers that were on the file server..

Claymoore

It should be the World Wide Web Publishing service. If that service is running as Local System Account, try adding the server's Active Directory account to the permissions tab on the shared printer. The server account is hidden, but the name is in the format domain\server$ - for example Contoso\WebServer$ .

You could also try running the CompatWS.inf security template (from the XP CD or you can probably download it from MS) on the workstations. This does a lot of things, but one of the things it does add the Anonymous User to the Everyone group. Since the Everyone group should have rights to print on the shared printers, this should also allow the web server to print to the printers. However, this security template also empties the Power Users groups on the workstations, so if you are relying on that group for anything this security template could break it.

BigTone

Claymoore wrote:

It should be the World Wide Web Publishing service. If that service is running as Local System Account, try adding the server's Active Directory account to the permissions tab on the shared printer. The server account is hidden, but the name is in the format domain\server$ - for example Contoso\WebServer$ .

You could also try running the CompatWS.inf security template (from the XP CD or you can probably download it from MS) on the workstations. This does a lot of things, but one of the things it does add the Anonymous User to the Everyone group. Since the Everyone group should have rights to print on the shared printers, this should also allow the web server to print to the printers. However, this security template also empties the Power Users groups on the workstations, so if you are relying on that group for anything this security template could break it.

I was hoping that adding the server account would fix it but it hasn't as of yet. I don't see a WWW publishing service in the list of users/groups/computers....

I can try the compatws.inf next...

BigTone

another note our other printers that are on print servers have no problems printing... its just the one local printer that is having the issue.

Claymoore

BigTone wrote:

I was hoping that adding the server account would fix it but it hasn't as of yet. I don't see a WWW publishing service in the list of users/groups/computers....

I can try the compatws.inf next...

The WWW Publishing Service is on the Web server itself. You can find it by going to Computer Management and then going to Services under the Services and Applications section. The WWW Publishing Serivce should be the last service listed - there is a Log On As column that will probably list Local System. That Local System account is really the domain\server$ account.

BigTone

Claymoore wrote:

BigTone wrote:

I was hoping that adding the server account would fix it but it hasn't as of yet. I don't see a WWW publishing service in the list of users/groups/computers....

I can try the compatws.inf next...

The WWW Publishing Service is on the Web server itself. You can find it by going to Computer Management and then going to Services under the Services and Applications section. The WWW Publishing Serivce should be the last service listed - there is a Log On As column that will probably list Local System. That Local System account is really the domain\server$ account.

Ok got it, actually our server (Server1) was listed in users/computers/groups account. Is this different from the hidden one?

**Edit**

Ok it came in as /Server1$

Still not working though...

I'm really perplexed.

Claymoore

BigTone wrote:

another note our other printers that are on print servers have no problems printing... its just the one local printer that is having the issue.

So the printers that are SHARED off a print server work, but the printers that are NOT SHARED off of the workstations don't work. If the web server itself is doing the printing then in order for it to print to the workstation printers, the workstation printers would need to be shared and installed on the web server. After you share them, you may need to add the server account on the permissions tab of the shared printers.

BigTone

none of the printers on the web server are shared. All print jobs are sent through the webb application and they spool through the web server and then are sent to the printer, whether its a print server or a local PC.

Claymoore

I must be missing something, because I am not understanding how a print job that is created and spooled on a web server in the server room is expected to appear on printer attached to a workstation on the other side of the building. Are you sure the printers weren't shared off of the workstations before the AD rollout?

BigTone

Claymoore wrote:

I must be missing something, because I am not understanding how a print job that is created and spooled on a web server in the server room is expected to appear on printer attached to a workstation on the other side of the building. Are you sure the printers weren't shared off of the workstations before the AD rollout?

Well, the web server should be pushing the print job to the local printer. But it doesn't get past "Printing - Spooling" on the web server printer. I tried sharing the printer too so that doesn't help.

I'm 100% sure that our printers aren't shared off the workstations because we still have offices, including our head office that I'm in that are still under the NT domain w/ local printers set up the same way.

Sie

Sorry im a little confused but will try and help.

Does this happen when printing from all clients?

Does this happen when printing to all printers?

What happens when you print directly from the Web Server?

What happens when you print directly from the machine the printer is attached to?

What part of the setup is running the spooling?

The Client? The Web Server? The Workstations?

Does the Print Server have enough space to process the print requests?

Maybe its just been a long day for me but I having trouble understanding how you have it setup so just suggested things I may check first on common printing problems.

Is this your setup?:
Web Server > Workstation > Printer

BigTone

Sie wrote:

Sorry im a little confused but will try and help.

Does this happen when printing from all clients?

Only to ClientA who has a local printer

Does this happen when printing to all printers?

No, printers connected Webserver - > Print Server - > Printer print fine

What happens when you print directly from the Web Server?

Test page/Job sits in the printer que Printer - Spooling

What happens when you print directly from the machine the printer is attached to?

Same

What part of the setup is running the spooling?

Spools from the webserver

Does the Print Server have enough space to process the print requests?

Brand new server so there are gigs free

Is this your setup?:
Web Server > Workstation > Printer

Yes

hetty

How old is the app? And was it coded specifically for IE 5, 6, 7 ?? What version of IIS was it hosted on in the past or is it the same version, server etc?

This all post migration yes?

BigTone

hetty wrote:

How old is the app? And was it coded specifically for IE 5, 6, 7 ?? What version of IIS was it hosted on in the past or is it the same version, server etc?

This all post migration yes?

Pretty old, continually updated... Same version of IIS, hasn't changed, we have users on IE 6 and 7 using it now.

those of us in IT call it the abortion... so if that says anything. I'd like to blame the application, because I really think I'm doing everything on my end to allow it to print... it just doesn't make sense I dont' want to have a consultant come in here and click one button or something and have to drop cash on that when its probably something really obvious.


This all happened post migration... Day X it was fine and then day Y once we migrated and started testing things this is the one thing that really caused us an issue.

hetty

What was migrated?

BigTone

hetty wrote:

What was migrated?

We migrated the users and computers and their local web and file server over to NewDomain from the OldNT domain.

hetty

If you did a pre-migration backup I would restore to vm and compare the settings, if necessary I would even run the app from a vm. In terms of user productivity that may end up being the better option if you cant get to the bottom of the issue

blargoe

When you said you printed a test page, you mean you printed a Windows test page, or a test from the application itself? If it's only a problem with one PC and a local printer, have you tried to attach a different local printer?

Sie

So this is affecting just the one printer thats attached to a workstation and is printing fine from all other clients and all other printers.

So i understand this is a locally attached printer to a workstation and you cannot print to the printer from the web server or from the local mahcine?

Have you swapped the printer and tested this?

If you forward the printer port to another similar printer what happens?
(Thus printing to another printer)

Are you able to map to the printer directly from the web server or workstation without any errors?

From what you have said i think its a fault with the printer or the workstation settings (IE firewall blocking access to the printer)

This is assuming the workstation has no other purpose in the printing process other than hosting the printer.