I get the following error in Vista while trying to start/stop a Windows Service that I created.
Cannot open ServiceName service on computer '.'.
The same code works for XP. What should I do to solve this problem?
User Account Control (aka UAC). UAC means that the user is not running as an administrator. Your application needs to tell windows that it requires admin rights. I think this page explains it better than I can.
Just stumbled upon your question today, though you had asked it a while back :)
I was having a similar problem on Windows Vista while i was trying to start a .net based service that i had developed.
I opened the Properties dialog of the service and changed the Log On user to Local System (Previously i was trying to start the service using Network Service). On restarting the service i didn't get any error.
In case you are still wondering about the answer, this has worked for me. I hope it will work for you too.
Cheers!
Related
Thank you for your time :)
I'm sorry if this has been asked before, I just really need clarification.
Environment: server 2008 R2 64bit
Basically what im attempting to do is create an autonomous application that will load even if the server reboots.
I went ahead and wrote a wcf service that will do the workload.
All I need is a trigger that will start one web method. It needs to fire even if the website isnt loaded (visited).
So far all ive found are registry edits, and possible a batch file. I really dont like the idea and I wish I could do something else.
I was hoping to find something in iis7 that would either call the global.asax file or AppInitialize() in the service.
The only way ive been able to get it to fire is if I visit the application myself.
Thanks for any help!
:)
You Windows Server version actually has IIS 7.5, so you are in luck. Check out the new Auto Start feature:
Auto-Start Feature
The auto-start feature of AppFabric is built on top of the auto-start feature of Internet Information Services (IIS) 7.5, which is included in Windows 7 and Windows Server 2008 R2. In IIS, you can configure an application pool and all or some of its applications to automatically start when the IIS service starts.
I have done some research, based on the problem that my single server gives me when I try to open a document library in windows explorer from the ribbon menu item "Open in Windows Explorer".
The same problem occurs when I try to map sharepoint to a folder in windows explorer too.
The error is:
Your client does not support opening this list with Windows Explorer
From the net, suggestions are:
(Since I'm trying this operation from server itself) enable Desktop Experience
Install the KB907306 update.
Enable IIS webDav service (Some say, it's just for additional functions from the MS Whitepaper)
(Edit) Started webClient service
I've already done them. Nothing changed. Proper machine restart and iis too have done.
Need some serious advice.
Thanks in advance.
Not sure if we are having exactly the same problem BUT I have had similar problem while accessing SP via Windows Explorer in Windows Server 2k8.
What I done to fix it is following:
Install new server feature called Desktop Experience (it comes with WebDAV redirector, which allows you to connect to WebDAV) - Note: Server will need to be restarted.
In Services start WebClient service (go to properties and make sure it starts automatically)
You will now be able to access your sharepoint via entering network path such as \sharepointhost\application\myawesomeapplication\ etc.
Hope that helps.
If you are trying to do this from the server, test it from a server which is not on the SharePoint farm (or better yet, a client machine). Ensure all of your testing is done from machines which are not on the farm.
Do NOT enable the IIS WebDAV service, as SharePoint provides its own WebDAV service and the IIS one overrides it in the pipeline. Enabling this service is a sure path to breaking WebDAV.
If you have SSL enabled, you may be in for a rough time getting it to work. Start by understanding how to use the 'net use' command, and the #SSL suffix.
make sure your webdav is installed as feature
make the following registry fix (http://support.microsoft.com/kb/841215) :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Add a new DWORD "BasicAuthLevel" and change this to "2"
Restart your machine (and make sure it is enabled in IIS)
Make sure that WebClient windows service is running in the server. This shall appear in client operating systems like Windows 7, windows 8 however, on the server operating systems like Windows Server 2008, it shall be installed by enabling the server feature "Desktop experience" using Server Manager
This issue nearly killed me. I found that I was using a 64 bit version of my browser and that is'nt supported. I changed over to the 32 bit and it works.
I'm trying to integrate WiX into my automated build solution using TFS 2010 running on Windows Server 2008 R2. Everything seemed very easy, and then I get this:
light.exe: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
That's odd. But hey! They provided a link. That should help, right?
Error LGHT0217
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Not at all. These posts just describe a situation involving scripting engine registration, and the conditions they describe were not present. However, I came upon Re: (WiX-users) Why do I get ICE failures building from a serviceaccount? (2010-01-14) that seemed to indicate that if I used a domain account to run the Windows Installer service, it would work. It sounded like it was worth a shot.
"For whatever reason on Windows 2008 (I didn't test Vista, XP, 2003, 7, or
2008 R2) the MSI Service is only available from logins that either have
administrative access or are logins that are "interactive". Logins that are
from service accounts that to not have administrative privileges cannot
access the msi service and thus cannot run ICE tests."
However, when trying to start the Windows Installer service with my build service account:
Windows could not start the Windows Installer service on SKILLET-1. Error 1297: A privilege that the service requires to function properly does not exist in the service account configuration. You may use the Services Microsoft Management Console (MMC) snap-in (services.msc) and the Local Security Settings MMC snap-in (secpol.msc) to view the service configuration and the account configuration.
OK, Windows, so you're telling me that my build service account is missing some ambiguous permission that it needs to start up the service. Making it administrator should fix that right? Nope, that doesn't work either.
So I revert back to local system for the Windows Installer service account. This time I made the build service a local administrator, and lo, success! That's hardly a solution, though.
My next idea was to attempt to isolate the permission set that the build service would actually require to get this done. That would be a nice solution instead of having to add more accounts to the administrator set. Step 1: go into local security policy and add the build service account to all permissions currently given to Administrators. In theory, that should allow the build to succeed, and from there I could selectively remove permissions until I've isolated all the permissions that must be held in order for it to succeed.
Unfortunately, even with all the same permissions, the build will still fail unless the build service account is a member of local administrators. Why is this? What other things besides LSP have dependencies on the administrator group that I could have changed to bring my build service account to equivalence with administrators?
Current conclusion: the build service must be an administrator in order to avoid ICE validation errors.
Open questions:
Why didn't my permissions isolation idea work?
What is this mysterious Error 1297 being thrown when running Windows Installer Service as a domain user? There's almost no documentation I can find on this.
I too faced the same problem. After some struggling and googling I came to the solution that suppressing ICE validation in the WiX project would make the project compile.
Unfortunately I don't have a lot of technical information to give you but I will give as thorough a description as I can.
I have done a fresh install of Windows Server 2003 Enterprise (SP1). Performed all the updates including SP2 and installed McAfee Enterprise 8.7. Once I've completed doing this I open up the Windows Components installation and check "Application Server" which should install the base IIS installation.
The install runs fine and I reboot just for good measure. When I go into services I see IIS Admin started. Pulling up the IIS Manager reveals that the DefaultAppPool and the Default Web Site are both stopped. Attempting to start the Default Web Site results in no failure message and no entries in the Event Log. This doesn't surprise me terribly as it depends on the DefaultAppPool. When I try to start the DefaultAppPool after a few seconds I get an error "The service did not respond to the start or control request in a timely fashion." and there is still no messages written to the event log.
I've tried this exact installation procedure twice now with identical results. Any suggestions would be greatly appreciated.
I found a work around if not a complete solution. I installed and configured IIS before updating or installing McAfee. IIS worked fine. Since I got it working I didn't want to go back and do a fresh installation but now that I think about it I might have just needed to run updates one more time after installing IIS. The order I installed it did allow me to get it to working so good luck to anyone else that has this issue. I hope this helps.
We have an application that starts a WCF server and the app reads from it.
It starts and can be read fine on all Windows XP machines.
On our Vista machine, however, we get:
System.ServiceModel.AddressAccessDeniedException
"The process has no rights to this namespace."
System.Net.HttpListenerException
The URL is at localhost:
http://localhost:8731/ABC.Testing.Business.Core/SecurityService/?wsdl
The error message sent us here:
http://msdn.microsoft.com/en-us/library/ms733768.aspx
And we did what it said:
netsh http add urlacl url=... user=...
which changed the rights but the WCF service still cannot start on Vista.
Does anyone have any experience with this that could move us forward? Thanks.
I had a similar issue with Windows 7 running Visual Studio 2010. My solution was a simple WCF service library with a simple console project serving as the WCF service host.
My base address in app.config was "http://localhost:8080/BookService" and I forgot that I had to start Visual Studio as an administrator in order to get Windows to map that port to my app.
As soon as I started Visual Studio as an Administrator (right click, Run as administrator) it ran like a champ.
try reading through this blog post and see if it helps.
http://blogs.msdn.com/paulwh/archive/2007/05/04/addressaccessdeniedexception-http-could-not-register-url-http-8080.aspx
I was having the similar problem while running the Project in VS2013 on Windows 8 OS, this problem get solved when I started my project as administrator..
Try to start up your app as administrator.
Thanks
Mayank Nagar