(888) 881-CORE
How do I run my application in a normal user account with AlwaysUp?
Most Windows Services run in the powerful LocalSystem account. And that’s the default account used by AlwaysUp when you install your application as a service.
Indeed, you can see that preference on the Logon tab when adding your application in AlwaysUp:
As the instructions say, simply leave the checkbox at the top unchecked and Windows will run your application in the LocalSystem account.
However, if the LocalSystem account isn’t appropriate and you’d like to run your program a different account, you must override the default and specify the credentials for another account. You’ll have to enter a user name and its corresponding password:
Why not run in the LocalSystem account?
We’ve identified a couple of reasons why you may want to avoid the LocalSystem account.
Reason #1: Your application may fail outside of the account where it was installed
Many applications run in the LocalSystem account just fine. They start normally and do what they’re supposed to do, without any problems.
But some programs won’t work as LocalSystem for one simple reason: they were never installed in that account.
You see, when you install an application, it may do a lot more than simply copy its files to your hard drive. In fact, there’s a good chance that it will update your system in one or more of these ways:
Save important information in the Windows Registry. For example, it could record an account number under your personal HKEY_CURRENT_USER key.
Create or update environment variables with crucial configuration details. For example, it could append a folder to your PATH variable, to dictate what programs you can run.
Map a network drive, perhaps to give you access to a repository in the cloud.
The trouble is that those changes may only be visible to the person who installed the software. And when you start the software in a different account, it fails because it can’t find those essential settings.
In summary, if your application’s configuration is tied to the user who installed it, that application won’t function properly as LocalSystem. It’s best to run that program in the account where you installed it.
Reason #2: You may improve security by using a less powerful account
LocalSystem is a mighty, administrative user with full control over your computer. An application running in that account can do almost anything it likes.
While that arrangement may be convenient, what happens if the application is compromised by a security attack? Or if it contains a bug that wreaks havoc by deleting system files?
To remove those undesirable possibilities from the table, you should run your application in a normal user account, with ordinary permissions. Doing so will constrain your application, ensuring that it’s limited by the access rights and privileges associated with the account. In that way, your program won’t be able to do maximum damage if an attacker takes control.
Will AlwaysUp accept a domain account?
Yes, you can enter a domain account on the Logon tab. Simply provide the full user name, with the domain.
Note that AlwaysUp supports user names in the two main formats used by Windows. You can enter a down-level logon name (such as DOMAIN\UserName) or a user principal name (like UserName@example.company.com).
And if you rather not type, you can click the … button to the right of the User name field and select the user from the appropriate location:
Are Microsoft Entra ID/Azure Active Directory accounts supported?
Well, you can certainly specify an Entra ID/Azure AD account on the Logon tab. But, unfortunately, your service may not be able to start with those credentials.
While we’ve not been able to reproduce the problem ourselves, a few customers using Azure AD have reported that AlwaysUp failed to start their service and consistently returned a puzzling error:
The message clearly implies that Entra/Azure AD has a dependency on one or more Windows Services. However, the service has no dependencies and Microsoft has not documented any implicit relationships either. A head-scratching situation, to say the least.
Note that the dependency problem has nothing to do with AlwaysUp. In fact, the folks who encountered the issue got the same error when they used the Azure AD account with any Windows Service — without AlwaysUp involved. It’s an Azure AD account thing.
What happens to my AlwaysUp application/service if the account’s password changes?
If you change your password, your AlwaysUp application/service will continue to run normally. Windows won’t stop or interrupt it in any way.
However, once the service stops, you won’t be able to start it again. Windows won’t be able to launch it at boot either.
AlwaysUp will report a logon failure, like this:
While the built-in Services application will throw Error 1069:
And, unsurprisingly, the NET START command will also fail, citing Error 1069:
You’ll have to edit your application in AlwaysUp and supply the new password to fix the problem. Once you do that, AlwaysUp, Services and NET.EXE won’t have any trouble starting the service.
Please keep that in mind for the next time you update your password!
