The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation


Q&A: Why Can’t Non-Admins Start/Stop Windows Services Remotely?

Why Can't Non-Admins Start/Stop Windows Services Remotely?
  I’ve used Service Security Editor to give a group of non admins rights to start and stop services on a server. However when trying to do this remotely, access fails (they don’t have any other rights on the server). I assume they need rights to remotely access Service Control Manager?

Do you have any relevant article that explains how to do this, giving them only the required rights? I don’t want to add them as Power Users or anything like that that might enable them to log in to the server using RDP.

— Gordon

Hi Gordon, thanks for reaching out.

You’re on the right track here. Even though you’ve used Service Security Editor to grant permissions on the service, there’s still one more obstacle to overcome for normal user accounts. Let’s recap and dig into the solutions available.


Service Security Editor enables local control…

As you’ve seen, Service Security Editor will do the heavy lifting. With a few clicks, you can quickly setup your users to start, stop or restart any service you choose. And after your changes, they can use the NET command, the SC command or the Services application — whatever they like.

In our experience, most folks stop here because local control is all they need. But you require remote access as well, and that raises security concerns — especially for accounts without admin rights.


…But Microsoft established additional restrictions on remote access

Starting in Windows 10 version 1709 and Windows Server 2016 version 1709, only users who are local administrators on a remote computer can start or stop services on that computer. This technical article discusses the situation.

To overcome this restriction and allow your users control a service remotely, you have a couple of options. You can either:

  1. Promote your users to administrators on the remote computer. Since the remote access restriction only applies to non-admins, they will no longer be rejected when they come in as an administrator; or

  2. Add your service to the remote access check exemption list — the set of services that bypass the remote access restrictions and can be controlled remotely by normal users.

The first option may be the quickest and most familiar because it’s easy to switch a normal user to an administrator. However, going that route may have unintended security implications. Do you really want to empower your users to do anything they want on the remote server?

The second approach involves editing the registry, which, of course, brings its own concerns. But at least it doesn’t come with hidden security consequences. We recommend going that way, so let’s take you through it in the next section.


How to add your service to the remote access check exemption list

Fortunately, Microsoft makes it fairly easy to add a service to the remote access check exemption list. And once the service is there, your non-admin folks will be able to control the service as desired.

To add your service to the list, step by step:

  1. Start the Windows Registry Editor (“Regedit”) on the remote computer. Since it’s an admin tool, you’ll need to be an administrator to run Regedit:

    Start the Windows Registry Editor
  2. Navigate to this key:

    Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\SCM

    Go to the SCM registry key

    If you don’t see a SCM key — which is normal on some systems — create it by right-clicking the SecurePipeServers key on the left and selecting New > Key.

  3. In the left panel, right-click the SCM key and select New > Multi-String Value:

    Create a new Multi-String Value
  4. In the new value that gets created on the right, set the name to RemoteAccessCheckExemptionList:

    Set the name to RemoteAccessCheckExemptionList
  5. Double-click RemoteAccessCheckExemptionList to edit its value. In the window that comes up, add the name of your service. But be sure to use your service’s “real” name and not its display name, which may be different.

    For example, here’s what that looks like when we added Print Spooler, where the service name is Spooler:

    Add the name of your service to the list

    Feel free to add multiple services if you like. Just hit the return key, enter another name and keep going.

    Click OK once you’re done.

  6. Back in the main Registry Editor window, you should now see your service(s) in the RemoteAccessCheckExemptionList value:

    RemoteAccessCheckExemptionList value set
  7. Finally, close Registry Editor.

And with your service on the remote access check exemption list, your non-admin users with rights to the service shouldn’t have any trouble manipulating the service. The dreaded “access denied” error will be a relic of the past.


Coming soon: Service Security Editor will update the remote access check exemption list for you

Our team has already started sketching how to enable non-admin remote access with Service Security Editor. And once that new version of our free software is out, you won’t have to read technical articles from Microsoft or mess with the Windows Registry — unless you really, really want to. 🙂

Posted in Windows Services | Tagged , , , , , , | Leave a comment

Q&A: How do I Let Regular Users Monitor and Restart a Windows Service?

How do I Let Non-Admin Users Monitor and Restart a Windows Service?
  I see that you guys have a lot of tools for Windows Services. Maybe you can help me solve this problem.

We have an important service and only Admins are allowed to use it. If there’s an issue and the service needs to be restarted, regular users who aren’t in the Administrators group have to put in a ticket.

To reduce the support calls, we’d like to give certain regular users the capability to see if the service is running and restart it if it isn’t. What’s the best way to do that?

— Alex

Hi Alex, thanks for reaching out. We can definitely help you tackle this issue with our free Windows Service utilities. It should only take you a few minutes to implement the following two-step process and you’ll be good to go.


Step 1: Use Service Security Editor to allow the user to start or stop the Windows Service

By default, only administrators can manage a Windows Service. And more often than not, regular users are summarily rejected with an “access denied” error when they try to start or stop the service because they don’t have the necessary rights. That’s the first problem we have to fix.

For example, we have a regular user named “Hazel Jones” on our system. Because she’s not in the Administrators group, her attempts to stop the Print Spooler service using the NET command are consistently rebuffed:

Hazel cannot stop the Print Spooler service

Your team’s probably in the same situation as Hazel.

So here’s what you should do to allow your users to control your Windows Service. We’ll use Hazel and the Spooler service to illustrate:

  1. Download our free Service Security Editor program.

  2. Start Service Security Editor.

  3. Select your Windows Service from the list:

    Select your Windows Service
  4. Click the Open button.

  5. As you can see in the Service Security Settings window that comes up, only Administrators have full control over the service. For example, Hazel was nowhere to be found in our list.

    Click the Add button to add the non-admin account:

    Click the Add button to add a user
  6. Enter the account name and click OK:

    Enter the Windows account
  7. Back in the Service Security Settings window, select the newly added user in the top panel. Afterwards, ensure that the user has all the rights you would like to give them in the lower panel.

    For example, we granted Hazel full permissions over Spooler. She’ll be able to start, stop or restart the service whenever she likes:

    Hazel has full permissions to the Spooler service
  8. Click OK to save your changes. And exit Service Security Editor since we’re done with that program.

At this point, your non-admin user should be able to control your Windows Service. The NET command should succeed now, as it did here for Hazel:

Hazel stops the Print Spooler service

But even though your user can now stop the service, that alone won’t make it easy for them to do so! The truth is that very few folks are comfortable invoking the NET command from a prompt, and it’s almost as painful to explain how to drive the Services application. We can do better — and that’s the focus of the next step.


Step 2: Have your user install ServiceTray, to make it easy to work with the Windows Service

In this second part of the solution, your non-admin user will install another of our popular, free programs, ServiceTray. This helpful tool will make it obvious when the service is running — and allow the user to easily stop, start or restart the service whenever there’s trouble.

To set this up, your regular user should:

  1. Download and install ServiceTray. It should only take a couple of minutes to breeze through the straightforward process.

  2. Start ServiceTray.

  3. In the window that comes up, choose the Windows Service from the drop-down at the top. For example, Hazel selected the Print Spooler service here:

    Select your Windows Service in ServiceTray
  4. Next, click the Save button. That will create a shortcut in your Windows Startup Folder — the location holding the applications that Windows launches whenever you log in:

    DESCRIPTION
  5. Click the Done button to close ServiceTray.

The next time the user logs in, Windows will start ServiceTray automatically. After a few seconds, a new icon will show up in the “tray area” on the right of the Windows taskbar:

DESCRIPTION

If the icon doesn’t show up in the tray area, they may need to change their Windows taskbar settings to show the icon. Hazel had to make that change:

Show the ServiceTray icon in Taskbar Settings

Using ServiceTray

A quick look at the tray icon will tell the user if the service is running or not. The color of the icon will be:

  • Green when the service is running (as shown above).

  • Red when the service is stopped:

    ServiceTray: The service is stopped
  • Yellow when the service is starting, stopping or in any other state:

    ServiceTray: The service is stopping

To take some action on the service, click the icon to summon ServiceTray’s menu:

ServiceTray managing the Print Spooler service

From there you can start, stop, restart or even get information about the service — all with a click of the mouse.

Hope this helps!

Posted in Windows Services | Tagged , , , , | Leave a comment

AlwaysUp Feature Spotlight: Restrict Your App To Specific CPUs

Restrict Your App To Specific CPUs

What is the “restrict CPUs” feature?

Modern computers feature multiple central processing units (CPUs). Those CPUs are the brains of the system — constantly coordinating hard drives, memory and other components to complete various tasks on your behalf.

While Windows does a great job of keeping your CPUs busy, seamlessly assigning tasks to each one, the operating system exposes a few levers to help you make the most of your computer. One such lever is the ability to assign an application to run on specific CPUs. Put another way, especially for the technical folks, Windows allows you to set the affinity for a process or thread.

AlwaysUp piggy-backs on the native Windows processor affinity functionality and allows you to run your application on one or more specific CPUs that you choose. Read on to find out why that “CPU pinning” may be a good thing to do.


Why should I limit my application to one or more CPUs?

For the vast majority of computer users, monkeying around with processor assignments is a bad idea. The truth is that Windows does an excellent job of scheduling work to CPUs and it’s unlikely that you will do better.

But, of course, there are exceptions. Here are a couple scenarios where constraining an application to specific CPUs makes sense.

Scenario #1: You’re running a legacy application that doesn’t support multiple CPUs

Some older applications and games were written before multi-processors became commonplace. The programmers assumed that a computer has single CPU and didn’t worry about concurrent execution, where different parts of the program run at the same time. Oh how things have changed!

Programs from that bygone era will often crash when run on modern computers with multiple processors. The only way to get them to work reliably is to limit them to running on a single CPU.

Scenario #2: Your application is a CPU hog

Some applications are built to consume all the processing power available to them. They peg all CPUs at 100% because they have a lot of work to get through!

Unfortunately those CPU-hungry programs can negatively impact other programs running on the computer. As the CPU hogs greedily gobble all the CPU cycles available, they don’t leave much time for other applications. And that results in starvation.

If you happen to be running one of those impolite applications, it may be best to assign the processor-intensive program to all but one of the CPUs. The logic is that by leaving a single CPU as “spare”, you reserve capacity for other programs to run there, unencumbered.


How do I enable the “restrict CPUs” feature in AlwaysUp?

To activate the setting in AlwaysUp:

  1. Edit your application in AlwaysUp, either by double-clicking the entry or selecting Application > Edit/View from the menu.

  2. Switch to the Extras tab.

  3. Check the Run the application on these CPU(s) box.

  4. Select one or more CPUs from the list.

  5. Save your changes.

For example, on our server with 4 CPUs, here’s how we constrained an application to the first and second processors only:

Only run the application on CPU 1 or 2

As you might expect, you won’t be able to activate the feature if your computer only has a single CPU. In that case, the Run the application on these CPU(s) option will be disabled.


How do I confirm that AlwaysUp is limiting my application to the designated CPUs?

If your application is running in AlwaysUp, you can use the Windows Task Manager to confirm that the process is limited to the CPUs you’ve chosen.

To do so:

  1. Start Task Manager.

  2. Switch to the Details tab.

  3. Find and highlight your application’s executable (*.exe) file in the list.

  4. Right-click the entry and select Set affinity to summon the Processor affinity window.

  5. Confirm that the CPUs you selected in AlwaysUp are the only ones selected.

For example, we installed Ollama as a Windows Service and limited it to running on the first two CPUs:

We restricted Ollama to two CPUs in AlwaysUp

After starting Ollama from AlwaysUp, we started Task Manager, found ollama.exe on the Details tab and selected Set affinity:

Set the affinity for Ollama.exe

The Processor affinity window confirmed that Ollama can only run on the first two CPUs:

Ollama processor affinity

What are your best tips for using this feature?

Tip #1: Only assign CPUs if you detect a problem

In the words of the distinguished Donald Knuth, “premature optimization is the root of all evil”. That is to say, it’s best to avoid making adjustments before you have evidence that that’ll be impactful.

Applying that advice to this situation, you should first run your applications without CPU restrictions. The vast majority of programs will have zero problems in that context. You should only override the default if you encounter a problem that CPU pinning is likely to fix.

The reality is that your CPU constraints may prevent Windows from making the best use of your hardware. Keep in mind that Windows is designed to automatically and dynamically assign applications on the least-busy processor — and CPU pinning can sabotage efficient scheduling.

Tip #2: Don’t limit too much

As you consider restricting where your application can run, be sure to keep performance in mind. You don’t want to make your application suffer by starving it of CPU cycles.

Even with the best of intentions, you can easily create a problem if you limit your application to fewer CPUs than it needs. For instance, your application may slow to a crawl if you constrain it to a single CPU when it demands much more.


Posted in AlwaysUp | Tagged , , , , , | Leave a comment

AlwaysUp 16.5: Easily Install nginx as a Service, Survive Resource Leaks, and more

AlwaysUp 16.5: Easily Install nginx as a Service, Survive Resource Leaks, and more

AlwaysUp version 16.5 is out! Here’s what our team worked on in this new release.


The Application Advisor now supports the nginx web server

If you’re looking to run nginx as a Windows Service, you’re in luck. With the help of the versatile Application Advisor, you can now install nginx with a few clicks.

To take advantage of our expertise, start the Application Advisor (by selecting Application > Advisor from the menu) and choose nginx from the list of applications:

Choose nginx from the list of applications

After you click Next, AlwaysUp will ask you to for the location of your nginx.exe file. Just enter the full path and continue:

Enter the path to your nginx executable (nginx.exe)

In the next screen, AlwaysUp will ask for the location of the nginx server files:

Enter the nginx server files folder

From there, click Next and follow the straightforward prompts to complete the process. In a few seconds, you’ll have a new Windows Service that starts your nginx installation at boot and runs the web server continuously in the background.


Automatically restart your application if it’s using too many “handles”

Without getting too technical, a handle is a reference to an operating system resource. And as part of normal operation, Windows gives your application a handle whenever it does things like:

  • open a file;

  • start a thread;

  • use an icon/picture;

  • open a DLL;

  • write to the registry.

Unfortunately some applications never give those precious resources back to Windows. They just keep accumulating handles until they crash or hang.

If you’re running one of those misbehaving programs, AlwaysUp is here to help. The new “check handle count” sanity check will promptly restart your application if it hogs too many resources.

To deploy the new feature for an application already set up in AlwaysUp:

  1. Edit your application in AlwaysUp

  2. Switch to the Monitor tab

  3. Check the Whenever it fails a periodic sanity check and click the Set button on the right.

  4. In the Add Sanity Check window, select Check that your application doesn’t have too many resource handles open:

    Check that your application doesn't have too many resource handles open
  5. Next, set the maximum number of handles that your application should have open at any time:

    Set the maximum number of open resource handles

    Be careful with this setting. You don’t want to pick a value that’s too low because it will lead to unnecessary restarts.

  6. Follow the remaining, self-explanatory screens to complete the process and save your changes.

And with that new sanity check in place, AlwaysUp will monitor your application and promptly restart it if it consumes too many handles.


Other fixes & improvements

  • We added a couple of buttons to help you catch and reduce errors when entering a Windows account on the Logon tab:

    Easily reveal the password or validate your Windows account
    • Click the eye to show the password that you typed in;
    • Click the lock and AlwaysUp will check that the password works for the account you entered.
  • If you like, you can now prevent the Application Advisor from automatically popping up when you start AlwaysUp and no applications are installed. Just check the Don’t automatically launch… box when the Advisor starts up by itself:

    Don't automatically launch the Application Advisor
  • AlwaysUp now shows the CPU affinity in the “running” tooltip when the application is restricted to specific CPUs. It looks like this:

    Application CPU affinity information
  • Are you running Windows on your Mac inside a Parallels virtual machine? If you have trouble applying your registration code, please upgrade to this latest version of AlwaysUp. The problems have been fixed.

    AlwaysUp runs on Parallels Desktop

As usual, please review the release notes for the full list of features, fixes and improvements included in AlwaysUp version 16.5.


Upgrading to AlwaysUp 16.5

If you bought AlwaysUp version 15 (after December 2023), you can upgrade to version 16.5 for free. Simply download and install “over the top” to preserve your existing applications and all settings. Your registration code will continue to work as well.

If you bought AlwaysUp version 14 or earlier (before December 2023), you’ll have to purchase a discounted upgrade to use any version 16. Please purchase upgrades here — you’ll save 50% off the regular price.

See the complete upgrade policy for additional details.

Thanks for reading!

Posted in AlwaysUp | Tagged , , , , , , | Leave a comment

AlwaysUp Feature Spotlight: Automatically Reconnect Network Drives

Automatically Reconnect Network Drives

What is the “automatically reconnect network drives” feature? Why would I use it?

To answer those questions, let’s start with the basics. You can skip the next section if you already know what a network drive is and how it works.

Network drives, explained

A network drive is a drive letter that allows you to access data not stored on your computer’s hard disks.

To explain a bit more, a network drive consists of:

  1. A drive letter, in the range of A-Z, where the remote data will be available;

  2. The full UNC path of a folder on a remote computer.

For example in our company, each workstation has “P” — a network drive mapped to a shared folder on our server’s hard drive. You can see our P drive’s properties here:

The P drive is mapped

And with the P drive in place, Windows Explorer simply shows it alongside the other drives on the computer:

The P drive in Windows Explorer

So instead of typing in “\\ctc1\\data\” when working with programs and scripts, we can simply use “P:\” in its place — like other, normal folders on our machine. That’s because P is a helpful alias for the “\\ctc1\\data\” folder.

Maybe you have a “G drive” or a “W drive” at work? Those are network drives too, that share documents across your team. Aren’t they convenient?

Windows Services and network drives

By default, network drives are mapped in the context of a specific user. To say it another way, the network drives that you create are only available in your Windows account. That makes sense; not everyone may have access to the network locations that you can visit.

However, that approach creates an obstacle when AlwaysUp runs your application as LocalSystem — the default account for Windows Services. In that scenario, the drive you mapped in your account may not be visible to your application because it’s running in the LocalSystem account.

But even if you instruct AlwaysUp to run your application in a normal user account, Windows will not automatically restore your network drive letters. In that case, your application will still have access to the network location (via the UNC path), but the convenient drive letter will not be available.

AlwaysUp will restore your drive letters for you

When you enable the “automatically reconnect network drives” feature, AlwaysUp will cycle through your drive letters and restore each one. That way, the application you’re running with AlwaysUp will have full access to the network drives that it needs to do its work.

You don’t need this feature if your application doesn’t use a network drive

Of course, restoring network drives won’t do you any good if your application doesn’t use them! In that case — or even if your application uses UNC paths instead of mapped drives — you can ignore the “automatically reconnect network drives” feature. You don’t need it.


How do I activate the feature in AlwaysUp?

To tell AlwaysUp to automatically reconnect your network drives, edit your application’s entry in AlwaysUp and check this box on the Startup tab:

The option to automatically reconnect your network drives

How do I know if AlwaysUp hasn’t mapped my drive?

If AlwaysUp was unable to restore a network connection, you’ll see an error in the activity. It should show up in the activity panel (as shown in the screenshot below) or when you generate a report by selecting Application > Report Activity from the menu:

Error restoring a network drive in AlwaysUp

AlwaysUp isn’t reconnecting my drive. Help!

For unusual situations like this, we recommend troubleshooting from a command prompt launched from AlwaysUp. Follow the directions and once the command prompt comes up on your screen, change directory (CD) to the drive. Hopefully Windows will return a helpful message that sheds some light on the problem.

In some circumstances, Windows may require you to enter the password to restore the network drive. Naturally, those drives cannot be reconnected without some help. The next section presents an alternative way forward.


How do I map my drive when AlwaysUp cannot do it automatically?

If AlwaysUp fails to map your drive automatically, you should map the drive with a script and configure AlwaysUp to run that script before it launches your application. Here’s the step-by-step process:

  1. Compose a version of the NET USE command that maps your network drive.

    For example, your command may look like this if you need to provide a password to map the H drive:

    net use H: \\fileserver1\shared-documents /user:mjones [mjonespassword] /persistent:yes

    Test to ensure that your command does the trick when you run it from a prompt.

  2. Save your command to a batch file (*.bat). Be sure to protect the file from non-authorized personnel if it contains a password!

  3. Start AlwaysUp and edit your application.

  4. Switch to the Startup tab. From there, check the Run the following program/batch file option and provide the full path to the script you created in step 2:

    Map your network drive at startup
  5. Save your updates.

With that change in place, AlwaysUp will map your drive whenever it starts. And after doing that, AlwaysUp will launch your application — with your drive ready and available.


Posted in AlwaysUp | Tagged , , , | Leave a comment