I suddenly cannot start IIS anymore on my Windows 2008 R2 server. The depending "Windows Actication Service" does not start.
In the Event Viewer I can see the following message:
"The Windows Process Activation Service failed to generate an application pool config file"
I've checked all IIS config files for typo's, none can be found.
I've tried to remove the IIS role from the server, which results in an error.
I'm totally desperate here. I've looked on Google for several hours, but none of the suggestions I've found helped.
Something has messed up permissions and the user account under which WAS runs does not have permission to create its working files. Probably you installed a service pack or similar.
Rebuild the box and apply all service packs to Windows before you install WAS, and then let it update itself and then install your own stuff.
Rebuilding boxes is no fun and takes far too long. Learn to use virtualisation and undo disks.
If you have another working server, you can import IIS configuration from there via Shared Configuration. I was able to resolve this error by doing so.
Related
I am trying to install GoCD Server 19.1.0 64 bit on my Windows 10 64 bit machine. Installation went through without any issue, however, I am getting the following error on starting Go Server service.
I tried to run service under Local System Account as well as specific admin account but not luck so far.
I also tried setting NoInteractiveServices registry from 1 to 0 (at \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows) but still getting the same error.
Please let me know if any of you have faced this error and know the solution.
Services
The Go Server service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs.
OK
Thanks in advance,
ND
You should look at GoCD's Log files to find out what happened, and why GoCD stopped.
Thanks #moritz for the info. I did not find any files under logs folder as it was failing with Access Denied error while writing to logs files. Not sure what was the reason behind that but this is how I fixed it.
I re installed the Go Server, this time I have selected C:\Program Files (instead of default C:\Program Files (x86)) and selected Open Java instead of providing path of JRE installed locally.
This worked in my case, however, feel free to let me know if you see any problem in this approach.
ND
I keep getting this error:
Error 1061: The service cannot accept control messages at this time
This happens when I attempt to stop the service installed using InstallUtil from this location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe
I am attempting to debug the windows service in question. My problem is that everytime I attempt to introduce changes to the codebase, the computer "A physical machine - Dell Precision T3500" requires that I restart the entire machine to completely uninstall the service, before I do a reinstall.
I have looked at this Link and it is not helpful in my scenario as I would first have to stop the service to be able to gain full access to the location where my build is generated to.
Whilst the service is attempting to restart before I do the restart of PC, when I attempt to build the service from my code, I get this interesting error from the compiler:
Error 16 Unable to copy file
"obj\x86\Debug\X_WindowsService.exe" to
"bin\x86\Debug\X_WindowsService.exe". The process cannot
access the file 'bin\x86\Debug\X_WindowsService.exe' because
it is being used by another process. X_WindowsService
Because of the error above I also think this is why I am not able to use the SO solution from here.
Does anyone have a clever idea for me to go through to bypass having to restart the machine as I debug and make changes to my codebase?
I also had a look at this link from SO but it has no marked solution, I also tried one of the Microsoft forums for a solution but it too has no applicable solution as they recommend the restart which I am trying to avert.
I feel so silly after finding this solution. I should most certainly have used the KISS principle for this one.
Turns out, all I had to do was look for the service's process from task manager and simply end the task. After that a refresh to my services list shows the service status as blank, meaning it has completely stopped without a restart of the machine.
I've downloaded oracle 12c on my personal laptop. Check system compatibility (alls good). However, towards the end Im getting an error stating "Oracle Services for microsoft transaction server" denied".
Please assist,
Googling the error message leads to this as the first result:
http://www.dba-oracle.com/t_ins_20802_oracle_services_for_microsoft_transaction_server_failed.htm
Which basically says to ignore the message and run the Database Configuration Assistant manually to finish configuring the database.
When an installation fails, you should check the installation log for more details.
In my case, the log file said "hostname too long", so I shortened the host name and was able to do a successful install.
I faced the same issue recently and it was regarding [INS-20802] Oracle Database Configuration Assistant failed error. I think the solution for it will of help in your issue too.
I tried several of the following methods for resolving the issue :-
Disabling Windows UAC
Disabling firewall
Disabling antivirus - mine was a fresh VM, so disabled Windows Defender
Adding localhost IP i.e., 127.0.0.1 to the hosts file etc.
but none of them helped.
At last I found this, which suggested installing Microsoft Visual C++ 2010 Redistributable Package (x86) and this solved the problem in a matter of seconds! I just had to click 'Retry' on the installation dialog.
Do you have local "Admininstrator" rights on the account that your are installing Oracle into?
The Oracle Universal Installer is trying to create the MTS service and access is being denied. This is why I usually don't take the default install, and use the "custom" install and select the components I want. OUI will then work out the dependencies and install the correct components.
With this type of failure, you should have had an option to "ignore/skip" the error and the installer should continue and install the database objects - you shouldn't need to re-install the database objects as the the MTS service component should install after the data objects are created and they are not reliant on each other. Unfortunately the installer status will still show "failed" because of that one component failing.
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 adding WMI publishing to a .net framework 3.5 based windows service that is running under the 'network service' account.
According to a document I came across on MSDN, the 'network service' account should by default have WMI publishing permissions. ("By default, the following users and groups are allowed to publish data and events: ... Network Service, ...")
However, when the service calls Instrumentation.Publish(myStatusClassInstance), it throws a DirectoryNotFoundException;
System.IO.DirectoryNotFoundException was unhandled
Message: Could not find a part of the path 'C:\Windows\system32\WBEM\Framework\root\MyWMINamespace\MyService_SN__Version_1.0.3686.26280.cs'.
..so it looks like System.Management.Instrumentation tries to generate code on the fly, and when running under network service it targets a directory where network service has no permissions.
What is the best fix/workaround for this? Can I override the code-gen target dir in app.config or in code? I don't want to have to fiddle around with file system permissions when deploying the service...
Update: I think this is a 'feature' where older FX code clashes with newer security settings in Win7. Internally the WMI managed classes retrieves the WMI installation directory from registry, and uses that as the output path for generated code. Unfortunately a lot of users are not allowed to (or supposed to) write stuff under %SystemRoot%... ...I filed a connect bug (#530392) to see if MSFT can bring any clarity and/or provide a fix or workaround.
Update 2: I'm guessing that for normal user accounts this is not an issue, because UAC virtualization will kick in and store the files elsewhere. However, apparently the 'network service' account is not covered by UAC virtualization..(?)
Update 3: Added 550pt bounty. Simple constraints: .net framework 3.5 based windows service, running as network service, need to be able to publish data through WMI using System.Management.Instrumentation on Win7 and Win2008[RTM & R2] with default permissions/security settings and without resorting to modifying framework internal/private members using reflection. 'Out-of-the-box' but clean solutions welcome. Will open a second related bounty-Q as a placeholder for another 550pt if SO allows.
Bounty update: I intend to double the bounty for this Q through a second hand-in-hand question that will serve as a bounty placeholder:
https://stackoverflow.com/questions/2208341/bounty-placeholder ( <-- Apparently this was not allowed, so the bounty placeholder question got closed by the SO etiquette police.)
Update 4: This gets better and better. I noticed that installutil was writing the missing files to c:\windows\syswow64...etc..., so I realized that I was using the 32-bit version of installutil to install the service, but the service was running as a 64-bit process. The obvious side effect was that code generated when installutil was running ended up under syswow64 (the 32-bit system directory), while the service was looking for it under the 64-bit system directory (system32). (<-- off topic, but I really like how MSFT managed to switch around the names there... :) ).
So I tried installing the service with the 64-bit version of installutil. That failed miserably with permission errors in the %sysroot%\wbem\framework...etc... path. Next I recompiled the service as x86 and registered it again using the 32-bit version of installutil. That resulted in an entirely new exception:
System.Exception: The code generated for the instrumented assembly failed to compile.
at System.Management.Instrumentation.InstrumentedAssembly..ctor(Assembly assembly, SchemaNaming naming)
at System.Management.Instrumentation.Instrumentation.Initialize(Assembly assembly)
at System.Management.Instrumentation.Instrumentation.GetInstrumentedAssembly(Assembly assembly)
at System.Management.Instrumentation.Instrumentation.GetPublishFunction(Type type)
at System.Management.Instrumentation.Instrumentation.Publish(Object instanceData)
at SomeService.InstanceClass.PublishApp(String name) in e:\work\clientname\SomeService\SomeService\WMIProvider.cs:line 44
at SomeService.SomeServiceService..ctor() in e:\work\clientname\SomeService\SomeService\SomeServiceService.cs:line 26
at SomeService.Program.Main() in e:\work\clientname\SomeService\SomeService\Program.cs:line 17
...getting closer...
I believe the problem is not with publishing data, but with registering that type in WMI for the first time.
If you examine the System.Management.Instrumentation code in reflector, or some other disassembler, you'll see that wen the assembly that is about to publish hasn't been registered, then the code will try to register the assembly and save the assembly info in a specially named sub directory under the WBEM installation folder.
I suspect that if you run code to publish the WMI data as an administrator first, it would register the assembly and then the Network Service account would have the permissions to do the normal publishing.
Have you inspected your assembly with the installutil? That should give you a log of the installation issues. (But since you can't run it as the Network Service account, it might not show the problem you're having.)
Also, are you sure this service must be run under the Network Service account?
Because of the vulnerability risk in running Windows services in privileged accounts, Microsoft has made these special service accounts with some limitations, which were strengthened in Vista and Win7. Since Vista, Microsoft has limited the number of services running under this account in favor of less-privileged ones (see this article). The Network Service account (aka "NT AUTHORITY\NETWORK SERVICE") can access the network (acting as the local machine account PCNAME$), but it has reduced rights on the local machine (unlike the Local System account).
Have you checked the WMI security permissions for the branch your assembly is using? Run wmimgmt.msc and dig in... When I did a quick check of some random branches, I could see that the Network Service account did not have write rights.
Lastly, I would suggest using Sysinternals' ProcMon, which would allow you to filter to just that process and see if there are any Access Denied errors in file or registry settings. This tool has solved many problems for me over the years.
Not sure if you raised it or someone else but please have a look:
http://connect.microsoft.com/VisualStudio/feedback/details/530392/wmi-publishing-fails-on-permission-error-please-provide-a-way-to-override-codepath-in-system-management-instrumentation-schemanaming-in-app-config-web-config
This may help you to understand the root cause of the issue better