asked on

Permissions Issue Prevents Service Manager from Controlling Service

We have services that have been developed in .NET under Visual Studio 2008. The services install with a service manager application that provides a GUI to the service to stop, start, pause it and view its own application error log. We've had no trouble with these services under Windows Server 2003. Now I'm doing some testing on WS2008 and have run into a bizarre permissions issue that has me stumped. I installed the service from the machine's local admin account and installed if for "All Users". Everything works fine from the local admin account. Also works fine from the domain admin account, AND the developer's domain account which has domain admin privileges. But from my domain account, which is set up exaclty the same as the developer's account, I cannot control the service from the service manager GUI. I CAN control it from the Windows Services applet, but NOT from our GUI/manager program. Applicaton log error is below. I tried deleting my user profile from the WS2008 machine and recreating it, but still no luck. Any ideas? Thanks.

Begin application log error:
Log Name: Application Source: DeltaPatternAgentMgr
Date: 4/19/2010 10:31:03 AM
Event ID: 0 Task Category: None Level: Error
Keywords: Classic
User: N/A
Computer: LABSRV1.vsoffice.com
Description:
svcStart_Click error System.InvalidOperationException: Cannot open Delta Pattern Agent service on computer '.'. ---> System.ComponentModel.Win32Exception: Access is denied
--- End of inner exception stack trace --- at System.ServiceProcess.ServiceController.GetServiceHandle(Int32 desiredAccess) at System.ServiceProcess.ServiceController.Start(String[] args) at System.ServiceProcess.ServiceController.Start at PatternAgentMgr.Form1.svcStart_Click(Object sender, EventArgs e) Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="DeltaPatternAgentMgr" /> <EventID Qualifiers="0">0</EventID> <Level>2</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2010-04-19T15:31:03.000Z" /> <EventRecordID>1835</EventRecordID> <Channel>Application</Channel> <Computer>LABSRV1.vsoffice.com</Computer> <Security /> </System> <EventData> <Data>svcStart_Click error System.InvalidOperationException: Cannot open Delta Pattern Agent service on computer '.'. ---> System.ComponentModel.Win32Exception: Access is denied
--- End of inner exception stack trace --- at System.ServiceProcess.ServiceController.GetServiceHandle(Int32 desiredAccess) at System.ServiceProcess.ServiceController.Start(String[] args) at System.ServiceProcess.ServiceController.Start at PatternAgentMgr.Form1.svcStart_Click(Object sender, EventArgs e)</Data> </EventData> </Event>

End application log error

ASKER CERTIFIED SOLUTION

Netman66

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

tcianflone

ASKER

Interesting. I set the local security policy for Run all Administrators in Admin Approval Mode to Disabled and now I can control the service from the service manager GUI that we deploy. Why do you suppose this is happening only with my account and not the developer's account, which has the same domain privilege level as mine? Any additional troubleshooting you suggest?

Netman66

It may be an ownership/permission issue that is carried over from the Dev account and pushed down to the file level.

Re-ACL the files perhaps? Change ownership to Administrators also.

tcianflone

ASKER

Looks like by default upon installing the service and service manager, the owner is set to SYSTEM. I checked the security tabs of both the service exe and the service manager exe and SYSTEM owns them both. You are suggesting I set the ownership to Admins, correct? Admins and both my account and the developer's account have full control. How would you suggest I re-ACL the files as I have never had to do that? Thanks.

Netman66

If System owns them, then is it set to interact with the desktop?

I'm not sure re-ACLing them is necessary if the owner is already not a specific user.

You could certainly try changing the owner to the Administrator's group for testing.

tcianflone

ASKER

Making the UAC change fixed the problem, but I still don't know why this was an issue on this one service installation where other similar ones did not exhibit this same issue.