I have a rather complicated toolchain so prepare for a lengthy post until getting to the problem:
I managed to get PDFCreator and a virtual PDF creating printer under Windows 7 running in server mode as a service. Next step in the process is PDFCreator calling a VBScript after the PDF is created. The script uploads the PDF to our server via WebService and polls the server for a resulting PDF. When the resulting PDF has been downloaded, the VBScript needs to print it to a confiured printer.
Now for printing I was using the integrated COM object of PDFCreator which gives access to GhostScript. This worked perfectly onder Windows XP for any account the PDFCreator service was started. For example as a domain user to have access to shared printers from the VBScript, as the user context is the same as the PDFCreator service.
Now I tried the same for Windows 7 and used the "local system" account as before, because my test printer is a local one (and works, i.e. TestPage). Effect is that the wscript stays in the task manager and never finishes. Next I activated Interactive mode for the service and a saw Ghostscript asking for the printer to print to. The Printer does exist as I checked before calling GS within the VBScript, but out of any reason GhostScript does not see the printer although in the dialog opened to select the printer, the printer is there.
After days long searching and unsuccessfully trying even a dedicted new administrator account for the servive with no success I finally came up with a way to get it working. Changing the user for the PDFCreator service to "locale service" I first got an error that the PDFCreator COM object creation failed. Okay I thought this makes sense, as "locale service" has less rights that "locale system". I got around this limit by changing the access right under comexp.msc and granted "locale service" rights for local and remote COM and Script access. Voilá, everything worked.
What I do not understand: Why is Ghostscript under the "locale service" account capable to find the printer although the account has less rights that "locale system"?
And: Which access right do I need to set for "locale system" or any other user account to make it work?
Or: Is there a comprehensive list of detailed differences between these accounts?
Thank you very much and greetz,
GHad
The answer can be found here: KB184291
It's about ASP/IIS running under "local system" account and cannot print because the printers are not available under the .DEFAULT user. Copying over registry entries helps.
Greetz,
GHad
Related
I have a puzzling situation with the Inno Setup FileExists function.
Here's the situation. I have three networked computers with like WORKGROUP names.
1) Windows 7 32-bit
2) Windows 7 64-bit
3) Window XP Service Pack 3
1) and 3) have been setup as servers with read-write shares, ex. ShareExe and ShareData
The problematic Inno Setup creates shortcuts to the executable in the ShareExe folder. It asks the user for the ComputerName of the server and then uses FileExists to verify correct input.
Running this setup on the XP (3) machine and specifying 1)'s computername works just fine, however when running the setup on the Win7 64-bit PC and specifying the same ComputerName as with XP, causes the FileExtsts test to fail.
Strangely, I can go to Network Places and open the ShareExe folder and successfully run the executable. My question is, "why does Inno FileExists fail only on the Win 7 64-bit machine?" I cannot find anything in the reference materials that suggest any version differences with FileExists. (I also tried FileSearch with the same results).
TIA
In Windows 7 (and Vista) with UAC enabled, by default network credentials and drive mappings are not shared between admin and non-admin contexts, even for the same user.
By default, Inno elevates to admin permissions (via PrivilegesRequired=admin), since most installations must (and should) be performed per-machine by an admin user. However this means that any credentials prompted for or saved by Explorer when browsing for the desktop are not available to it.
When files are accessed directly by APIs (as with FileExists), Windows will typically try to silently connect to the server using the same username/password as was used to log into the PC; if this fails then it just reports an error since it has no way to prompt for alternate credentials at that point. So if you can ensure that the login details on both PCs are the same, then it should work. (You usually get this for free on computers connected to a domain, but not a workgroup.)
If that isn't possible, then something else you could try would be to force the access via a shell dialog -- if the FileExists fails, then use GetOpenFileName to prompt the user to find a specific file in that folder, using the same initial path. I haven't tested this, but I think this should result in Windows displaying a credential prompt and then you should be ok after that.
(If this is for an internal app, then another option is to disable the separation of credentials [via a security policy setting] or UAC entirely, though the latter isn't really a good idea. Of course this isn't tolerable for a general-release app, and it's cleaner if you solve it one of the other ways anyway.)
I need to programmatically create a new Windows account for running a Windows service I recently developed.
Due to lack of sufficient privileges I cannot use any of the existing service accounts (LocalService, NetworkService and LocalSystem), so I have to create my own account during installation of my service.
Unfortunately, I have no idea on how to accomplish this from code (C#). However, I know that the steps I have to go through include:
Create the account
Deny account log on via console
Grant log on as a service.
Add the account to the local administrators group on the PC
My service must install and run on all Windows PC operating systems ranging from Windows XP SP3 and up.
Question: Which command line tools are available for this purpose (I can very well call those command line tools from code)?
Further, any relevant links, code snippets or scripts will be very much appreciated!
If you just want a single command you can probably do:
net user /ADD "newuser" "Pass phrase" /passwordchg:no
However I looked into 'grant logon as a service' in the past, and had to download an additional .exe from a Windows Server Resource Pack to do this. That may be a pain as you'll need to redistribute the .exe.
Unless someone suggests a better way which uses only built in .exes I'd try and do this with one of:
Powershell
VBscript
I'm having a lot of problems trying to start an application as administrator on an application I'm writing when running it on XP Embedded.
The application runs as the shell for a limited user account and is touch-screen and keyboard-less with one user command being to run the touch screen vendor's calibration tool. This must be run as administrator.
No problem I thought, add user and password information to the ProcessStartInfo and all should be fine. No. The error I get is:
System.ComponentMode.Win32Exception: The specified service does not exist as an installed service.
From some investigation, I've found that:
My Process starting code is correct:
any application can be started successfully on XP Embedded when run as the limited user
any application can be run as Administrator on my own laptop
on XP Embedded, any application is regarded as being a service in the same way, including notepad
if I attempt to start a program from within process explorer, I simply get "Unable to execute process: Access is Denied"
I'm not an XP Embedded expert in anyways so I'd very much appreciate some help. I suspect that there's a configuration setting that has been set when building the XP image that specifically denies access to process creation and that the errors I'm being reported are actually mis-reports from software that's not assuming XP Embedded error codes.
Unfortunately, the people who make the base image aren't around right now so I can't get the current settings.
Thanks in advance if anyone's ever seen this before!
Kev
For the record, it turned out that the "Secondary Logon" service wasn't installed in the image.
The code I had reached down eventually into either CreateProcessWithLogonW or CreateProcessAsUser which ultimately depend on this service running. The "specified service" error was spot on, but not about what I thought it was about. No idea why I got that particular error from Process Explorer.
We have a WCF service that generates an Excel file off of a template and feeds it back to the client in a byte array. For some reason, we are getting an error when we try to do this:
sheet.PageSetup.CenterHeader = sheet.PageSetup.CenterHeader.Replace("[customerName]", customerName).Replace("[dateTime]", date.ToShortDateString());
When it hits this line, we get this error message:
No printers are installed. To install a printer:
In Microsoft Windows 2000, click Start, point to Settings, and then click Printers. Double-click Add Printer.
In Microsoft Windows XP, click Start, and then click Printers and Faxes. Under Printer Tasks, click Add a printer.
Follow the instructions in the wizard.
The service runs under the LocalSystem account. When we first deployed this service, it was to an x64 machine and had the same issue. Our dev environment is x86 so we moved the service to another server that was x86 and it worked fine for a while. It recently stopped working and is now giving us this error message again. I am pretty sure it was becuase of a mass windows update that was done on the app server recently.
Funny thing is, I tried changing the service to "allow interaction with the desktop" and it didn't work, but when our sysadmin did that same thing, it worked for one file generation but is not working now.
There are printers installed on the machine, both on domain accounts and local accounts. I've also tried running the service under a different account, but then I wasn't able to connect to the service due to some SSPI error. We tried using the Network Service account but then the app couldn't see the service at all. We've restarted the service after each change also to no avail.
What I do know about the "PageSetup" part of the sheet object is that it needs to have a printer installed to access it at all, even if you aren't printing. I was unable to figure out a way to trick the machine into thinking the LocalSystem account has a printer installed.
We figured out the problem, I had my config file still pointed at the x64 server :(
As to why it won't work on x64 (to my knowledge) - since office 2003 is x86, it needs an x86 print spooler in order to work correctly. I don't know of any way to get an x86 print spooler on an x64 OS so we just stuck it on the x86 server.
I'm writing a server running as a Windows service that by request invokes Firefox to generate a pdf snapshot of a webpage.
I know it is a bad idea to run a GUI program in service mode, but the server nature of my program restricts from running it in the user mode. Running a user-level 'proxy' also is not an option, since there might be no interactive user logged-in on the machine with the server running.
In my experiments Firefox successfully produced pdf when the service was running under a user account that was already logged-in. Obviously it didn't work in other cases: for Local System and user accounts that weren't logged-in. Under LocalSystem with 'Allow service to interact with desktop' option enabled I could see the Firefox started that reports that it's unable to find a printer.
Since it wouldn't be practical to require an opened user session for the pdf server to run, is there any workaround for this except running the whole thing from a virtual machine?
UPDATE: I figured that the problem wasn't really with account permissions, but with an invisible modal dialog that FF was waiting on while running in the service mode.
However it's still unable to create a pdf when FF is running under the LocalSystem account. FF says it can't find a printer and I'm wondering if this is a permission that could be somehow enabled?
You might want to try a different approach where you'd include some .NET PDF library (PDFsharp is a good, open source, choice) in your project and than use that in conjuction with WebBrowser control you'd also include in your project to render the PDF.
Don't forget to use STAThread attribute if you try this.
I've been through a similar conundrum with the MS Word running unattended. What you need to do is to login as the user you set up to be used to run firefox process and go through the process of setting up printers.
It is possible that just logging in as that user will be enough - there is some stuff performed during the first logon.
I apologize I was not clear enough - I mean you have to logon interactively using that account, configure the default printer, logout, and then run your service
Can you run the program as a Scheduled Task instead? The task can be assigned to a given user account which should work around the service limitations.
A couple of year ago I had a related issue: Shared Network Printer on pseudo-device starting up Ghostscript for PS->PCL translation and printing to real printer. The print-spooler service ran as Local System and the pseudo-device driver hat troubles executing Ghostscript from the service-mode. I was able to solve the problem by copying a couple of registry keys from the HKCU-hive to HKLM.