EXP Systems Forum: ASP.NET 2.0 and Network Service account

Author

Message

tedh7552
Newbie
Newbie

Joined: 10 Jan 07
Posts: 7

Topic: ASP.NET 2.0 and Network Service account
Posted: 21 May 09 at 5:53PM

I'm trying to get the Pro version to run on WS2003 in batch mode through IIS almost exactly like this past post:

http://www.exp-systems.com/forum_exp/forum_posts.asp?TID=351

A major difference being that I wish to continue using the 'Network Service' account.

My routine has no problem printing to a local printer (standard TCP port network printer on the server). When I point it at a PDF Redirect Pro batch printer, nothing happens. I get no exceptions or any other error message and no PDF. Nothing happens if I print to the default "PDF reDirect v2" non-batch printer as well.

Manually printing at the server works perfectly.

I did try copying the suggested files to:

C:\WINDOWS\system32\config\systemprofile\Application Data

...as you suggested in the post above to no avail.

I also try this: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q184291

...which in essence, creates default system printer setups which did not help and appeared to be unnecessay as I added a printer after that and had no problem printing to it.

I enabled logging within PDF Redirect. I see entries in the log if I use batch printer locally at the server. Through IIS/ASP, I see no entries for the attempt to print at all even though the event log (system) area says:

Document 10, document owned by NETWORK SERVICE was printed on BarcodeLabel4x2 via port PDF_REDIRECT_PORT:. Size in bytes: 2080; pages printed: 1

-------------------

PDF-RDPro version = 2.2.8

Any help would be greatly appreciated...

-Ted

IP Logged

Michel_K17
Moderator Group

Forum Administrator

Joined: 25 Jan 03
Posts: 1673

Posted: 21 May 09 at 11:10PM

Hi,

   Thank you for your complete description of the problem. I think it helped.

   Did you, by any chance, create the batch printer on a different account? If so, then the settings associated with the batch printer are still in the original user's account, and need to be manually transferred to your 'Network Service' account (look in the original user's account >> App Data >> PDF reDirect >> Batch Printers >> etc.

   However, you also mentioned that the main PDF reDirect printer is also not working, so I suspect the problem might be something else. This implies that the problem is with my printer port monitor, and to troubleshoot that requires a bit of gymnastics. I will send you an e-mail with instructions shortly.

   Hopefully I'll be able to help out to resolve the problem.

   Cheers!

Michel Korwin-Szymanowski
EXP Systems LLC

IP Logged

tedh7552
Newbie
Newbie

Joined: 10 Jan 07
Posts: 7

Posted: 22 May 09 at 2:49AM

Yes, the batch printer was created on the locally logged in administrative account. Then, I copied

C:\DocsNSettings\Administrator\Application Data\PDF Redirect directory and all subdirectories to

C:\windows\system32\config\systemprofile\Application Data\

as suggested in the post I quoted.

Of course, the 'Network Service' account is one of those phantom 'system' accounts that is treated oddly by the system. It cannot log in interactively. I gave it rights, however, to the C:\Program Files\PDF reDirect directory so it should have access to the DLLs and such and also gave it permissions to the batch printer specifically.

ASP/IIS recognizes the printer (batch printer called BarcodeLabel4x2). If I specify a printer that doesn't exist in the code (web page), I get an exception. I also verified that the Network Service account had full control access to the batch printer's output directory (somewhere within intetpub\wwwroot)

The main (default) PDF reDirect printer only doesn't work through the ASP print routing. All PDF reDirect printers both batch and interactive do work if I print to the through the locally logged in administrator account.

I feel like it's so close to working and it will be a great boon to get it running right.

Thanks for the help.

Note that the server is three feet away and I can do whatever is necessary. Sorry to dredge up an issue that you worked on a year and a half ago but I suspect that it will come up more and more as people create web applications where creating a local PDF is valuable.

-Ted

IP Logged

tedh7552
Newbie
Newbie

Joined: 10 Jan 07
Posts: 7

Posted: 22 May 09 at 12:39PM

This is a copy of the email I sent just to keep the thread more informative for people with similar troubles...

-------------------------------

Here's the results.

I had to give NETWORK SERVICE permission to C:\PDFR_portmon before it would show anything for its attempts. The PDFR_portmon.log has two attempts in it. One was from the interactive administrator user just printing a web page to the batch printer. The second is from an IIS attempt.

One thing I noticed is that its trying to read/write from C:\Documents and Setting\NetworkService\Application Data which it seems to think is successful but that directory doesn't exist.

Also included is a ProcessMonitor trace. There's many many entries in here of course but it does show Capture.exe getting started (under the system account).

Hope this helps...

-Ted

IP Logged

Michel_K17
Moderator Group

Forum Administrator

Joined: 25 Jan 03
Posts: 1673

Posted: 24 May 09 at 11:41PM

Hello Ted,

   Thank you for the log. I was helpful, and indeed, your observation is correct.

    Please make a copy of the following folder (and all sub-folders):
C:\Documents and Settings\Administrator\Application Data\PDF reDirect

and place it into:
C:\Documents and Settings\NetworkService\Application Data\PDF reDirect

    The most important file (in your case) will be that of the batch printer settings file (which is in a subfolder in the above path): once Capture.exe finds that file properly, it should continue with the conversion. Be careful to choose a batch printer setting which does not display the "Save As" dialog which would appear in that accounts workspace (which is not visible on the monitor). So, once you have the batch printer settings all sorted out, manually copy that file to the "NetworkService's account (as explained above).

    Similarly, if the batch file printer setting is not found, then Capture.exe tries to treat this is a regular PDF reDirect printer job, and tries to display the normal user interface - which again, will not appear in the user's workspace, and will get stuck in no man's land.

    Also, you might find that if you are currently within the 90 day evaluation period, it will eventually expire, at which point the program will cease to function (and the reason why will not be obvious as any error messages will not be displayed. If you are still using PDF reDirect Pro, and you plan to use the program to generate PDF files automatically without user interaction, then you should enquire about the Server License which includes a special automated registration process which will allow PDF reDirect Pro to work past the 90 day limit.

   Best regards,

Michel Korwin-Szymanowski
EXP Systems LLC

IP Logged

tedh7552
Newbie
Newbie

Joined: 10 Jan 07
Posts: 7

Posted: 25 May 09 at 2:59PM

It didn't work.

I was surprised to find that the directory c:\Documents and Setting\NetworkService actually did exist. It wasn't enough to 'Display Hidden' files. Explorer won't show it to you unless you also uncheck 'Hide Protected Operating System Files'.

Anyway, I copied the directory structure to

Network Service\Application Data\

I'm certain that it matched Administrator\Application Data\

I'm also certain that the batch printer will display no 'save as' as it has an output directory and automatic naming. If I print locally at the server, I get a PDF in the proper directory with no dialogs at all with the filename = the print job name.

No 90 day problems. It's fully registered.

As for DocNSettings\Network Service\Application Data\PDF reDirect Pro\temp ...there are plenty of '.ps' files in there. B00001234.ps and such. I'd guess there is one for every attempt I've ever made through the web site / IIS since file dates start when I first started getting it running. When I try another print job from the web page (IIS), another appears.

Included is a zip with two more (ughhh) process monitor traces. One is from an IIS job and the other is from a local, interactive print.

I filtered out all but capture.exe activity and compared them both. On the good (interactive) print job, you can see capture.exe start, read registry entries, and eventually access the prefs_v2.ini. Further on, it gets to the \Batch Printers\BarCode4x2.ini which is the batch printer settings file. On the bad (IIS) print job, the thread mysteriously exits after accessing some keys related to GRE. It never actually gets to where it attempts to access any ini/config type files in the application data directories. The two traces are identical until that point. Then the one continues happily along and the other just exits the thread.

Its very frustrating since capture.exe is using the system account in both cases... It would seem to be past the Network Service fight at that point.

-Ted

IP Logged

Michel_K17
Moderator Group

Forum Administrator

Joined: 25 Jan 03
Posts: 1673

Posted: 27 May 09 at 12:11AM

Hello Ted,

   Thank you for offering the easy way out. :-)

    I took a second look at the log files you sent, particularly the Process monitor outputs. Capture.exe is running as the System user - which is not completely unexpected since the print job started from IIS you said. For the long term, it sounds like you could use the new feature which allows the program to use the settings saved to the "All User" account for all users. This will be available in the next version.

    In the mean time, there a couple of things still worth checking.

    #1. Take a look at the batch printer settings file for the Network Service user: The first line should contain the name of the batch printer, and should not be blank

    #2, Take a look at the Prefs_v2.ini file for the Network Service user. The following line should be like this:
-->Pro_Mode=-1

    And not:
-->Pro_Mode= 0

    Cheers!

Michel Korwin-Szymanowski
EXP Systems LLC

IP Logged

Programming
EXP Systems Forum : PDF reDirect : Programming

Author	Message
tedh7552 Newbie Joined: 10 Jan 07 Posts: 7	Topic: ASP.NET 2.0 and Network Service account Posted: 21 May 09 at 5:53PM
	I'm trying to get the Pro version to run on WS2003 in batch mode through IIS almost exactly like this past post: http://www.exp-systems.com/forum_exp/forum_posts.asp?TID=351 A major difference being that I wish to continue using the 'Network Service' account. My routine has no problem printing to a local printer (standard TCP port network printer on the server). When I point it at a PDF Redirect Pro batch printer, nothing happens. I get no exceptions or any other error message and no PDF. Nothing happens if I print to the default "PDF reDirect v2" non-batch printer as well. Manually printing at the server works perfectly. I did try copying the suggested files to: C:\WINDOWS\system32\config\systemprofile\Application Data ...as you suggested in the post above to no avail. I also try this: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q184291 ...which in essence, creates default system printer setups which did not help and appeared to be unnecessay as I added a printer after that and had no problem printing to it. I enabled logging within PDF Redirect. I see entries in the log if I use batch printer locally at the server. Through IIS/ASP, I see no entries for the attempt to print at all even though the event log (system) area says: Document 10, document owned by NETWORK SERVICE was printed on BarcodeLabel4x2 via port PDF_REDIRECT_PORT:. Size in bytes: 2080; pages printed: 1 ------------------- PDF-RDPro version = 2.2.8 Any help would be greatly appreciated... -Ted
	IP Logged

Michel_K17 Moderator Group Forum Administrator Joined: 25 Jan 03 Posts: 1673	Posted: 21 May 09 at 11:10PM
	Hi, Thank you for your complete description of the problem. I think it helped. Did you, by any chance, create the batch printer on a different account? If so, then the settings associated with the batch printer are still in the original user's account, and need to be manually transferred to your 'Network Service' account (look in the original user's account >> App Data >> PDF reDirect >> Batch Printers >> etc. However, you also mentioned that the main PDF reDirect printer is also not working, so I suspect the problem might be something else. This implies that the problem is with my printer port monitor, and to troubleshoot that requires a bit of gymnastics. I will send you an e-mail with instructions shortly. Hopefully I'll be able to help out to resolve the problem. Cheers!
	Michel Korwin-Szymanowski EXP Systems LLC
	IP Logged

tedh7552 Newbie Joined: 10 Jan 07 Posts: 7	Posted: 22 May 09 at 2:49AM
	Yes, the batch printer was created on the locally logged in administrative account. Then, I copied C:\DocsNSettings\Administrator\Application Data\PDF Redirect directory and all subdirectories to C:\windows\system32\config\systemprofile\Application Data\ as suggested in the post I quoted. Of course, the 'Network Service' account is one of those phantom 'system' accounts that is treated oddly by the system. It cannot log in interactively. I gave it rights, however, to the C:\Program Files\PDF reDirect directory so it should have access to the DLLs and such and also gave it permissions to the batch printer specifically. ASP/IIS recognizes the printer (batch printer called BarcodeLabel4x2). If I specify a printer that doesn't exist in the code (web page), I get an exception. I also verified that the Network Service account had full control access to the batch printer's output directory (somewhere within intetpub\wwwroot) The main (default) PDF reDirect printer only doesn't work through the ASP print routing. All PDF reDirect printers both batch and interactive do work if I print to the through the locally logged in administrator account. I feel like it's so close to working and it will be a great boon to get it running right. Thanks for the help. Note that the server is three feet away and I can do whatever is necessary. Sorry to dredge up an issue that you worked on a year and a half ago but I suspect that it will come up more and more as people create web applications where creating a local PDF is valuable. -Ted
	IP Logged

tedh7552 Newbie Joined: 10 Jan 07 Posts: 7	Posted: 22 May 09 at 12:39PM
	This is a copy of the email I sent just to keep the thread more informative for people with similar troubles... ------------------------------- Here's the results. I had to give NETWORK SERVICE permission to C:\PDFR_portmon before it would show anything for its attempts. The PDFR_portmon.log has two attempts in it. One was from the interactive administrator user just printing a web page to the batch printer. The second is from an IIS attempt. One thing I noticed is that its trying to read/write from C:\Documents and Setting\NetworkService\Application Data which it seems to think is successful but that directory doesn't exist. Also included is a ProcessMonitor trace. There's many many entries in here of course but it does show Capture.exe getting started (under the system account). Hope this helps... -Ted
	IP Logged

Michel_K17 Moderator Group Forum Administrator Joined: 25 Jan 03 Posts: 1673	Posted: 24 May 09 at 11:41PM
	Hello Ted, Thank you for the log. I was helpful, and indeed, your observation is correct. Please make a copy of the following folder (and all sub-folders): C:\Documents and Settings\Administrator\Application Data\PDF reDirect and place it into: C:\Documents and Settings\NetworkService\Application Data\PDF reDirect The most important file (in your case) will be that of the batch printer settings file (which is in a subfolder in the above path): once Capture.exe finds that file properly, it should continue with the conversion. Be careful to choose a batch printer setting which does not display the "Save As" dialog which would appear in that accounts workspace (which is not visible on the monitor). So, once you have the batch printer settings all sorted out, manually copy that file to the "NetworkService's account (as explained above). Similarly, if the batch file printer setting is not found, then Capture.exe tries to treat this is a regular PDF reDirect printer job, and tries to display the normal user interface - which again, will not appear in the user's workspace, and will get stuck in no man's land. Also, you might find that if you are currently within the 90 day evaluation period, it will eventually expire, at which point the program will cease to function (and the reason why will not be obvious as any error messages will not be displayed. If you are still using PDF reDirect Pro, and you plan to use the program to generate PDF files automatically without user interaction, then you should enquire about the Server License which includes a special automated registration process which will allow PDF reDirect Pro to work past the 90 day limit. Best regards,
	Michel Korwin-Szymanowski EXP Systems LLC
	IP Logged

tedh7552 Newbie Joined: 10 Jan 07 Posts: 7	Posted: 25 May 09 at 2:59PM
	It didn't work. I was surprised to find that the directory c:\Documents and Setting\NetworkService actually did exist. It wasn't enough to 'Display Hidden' files. Explorer won't show it to you unless you also uncheck 'Hide Protected Operating System Files'. Anyway, I copied the directory structure to Network Service\Application Data\ I'm certain that it matched Administrator\Application Data\ I'm also certain that the batch printer will display no 'save as' as it has an output directory and automatic naming. If I print locally at the server, I get a PDF in the proper directory with no dialogs at all with the filename = the print job name. No 90 day problems. It's fully registered. As for DocNSettings\Network Service\Application Data\PDF reDirect Pro\temp ...there are plenty of '.ps' files in there. B00001234.ps and such. I'd guess there is one for every attempt I've ever made through the web site / IIS since file dates start when I first started getting it running. When I try another print job from the web page (IIS), another appears. Included is a zip with two more (ughhh) process monitor traces. One is from an IIS job and the other is from a local, interactive print. I filtered out all but capture.exe activity and compared them both. On the good (interactive) print job, you can see capture.exe start, read registry entries, and eventually access the prefs_v2.ini. Further on, it gets to the \Batch Printers\BarCode4x2.ini which is the batch printer settings file. On the bad (IIS) print job, the thread mysteriously exits after accessing some keys related to GRE. It never actually gets to where it attempts to access any ini/config type files in the application data directories. The two traces are identical until that point. Then the one continues happily along and the other just exits the thread. Its very frustrating since capture.exe is using the system account in both cases... It would seem to be past the Network Service fight at that point. -Ted
	IP Logged

Michel_K17 Moderator Group Forum Administrator Joined: 25 Jan 03 Posts: 1673	Posted: 27 May 09 at 12:11AM
	Hello Ted, Thank you for offering the easy way out. :-) I took a second look at the log files you sent, particularly the Process monitor outputs. Capture.exe is running as the System user - which is not completely unexpected since the print job started from IIS you said. For the long term, it sounds like you could use the new feature which allows the program to use the settings saved to the "All User" account for all users. This will be available in the next version. In the mean time, there a couple of things still worth checking. #1. Take a look at the batch printer settings file for the Network Service user: The first line should contain the name of the batch printer, and should not be blank #2, Take a look at the Prefs_v2.ini file for the Network Service user. The following line should be like this: -->Pro_Mode=-1 And not: -->Pro_Mode= 0 Cheers!
	Michel Korwin-Szymanowski EXP Systems LLC
	IP Logged