May 13, 2016
Applying update on a ColdFusion instance running with a non-admin user
May 13, 2016
Applying update on a ColdFusion instance running with a non-admin user
Newbie 25 posts
Followers: 0 people

You may run into issues if you are using a non-administrator user account to install ColdFusion updates manually, or if an installation is attempted from the ColdFusion administrator console when ColdFusion service is running with a non-administrator account. In such cases, the update may not install successfully. and may complete with errors.

The Windows user account used by the ColdFusion service should have the privileges to start and stop the ColdFusion service. The updater needs to stop the ColdFusion service, so that it can replace the class files used by the service. After the update is installed, the updater starts up the ColdFusion service. Similarly if the updater packages any updates related to the other ColdFusion services, such as ColdFusion Add-On/Jetty service or ColdFusion .NET service or ColdFusion ODBC service, it would stop and start these services as well.

To avoid running into the issue above, one can take either of the following 2 approaches: 

 – Stop the ColdFusion service manually before running the updater jar. Restart the service, once the update is installed. This, of course, would need to be done every time you install an update; or

 – Assign the ColdFusion user account the privileges to start/stop the service. This would be a one-time fix.

If you are using Windows 2003 server, XP you can follow this blog post, to assign start/stop privileges to the ColdFusion service user account. But, if you are on a later edition of Windows such as Windows 7 or Windows 2012 server, you can keep on reading.

Windows Service Controller command can be used to set permissions on a Windows service. We will be using the following 2 variants of the command :

SDSHOW : To display the permissions on a service. 

syntax : sc [<ServerName>] sdshow <ServiceName> <ServiceSecurityDescriptor>

SDSET : To set the permissions on a service.

syntax : sc [<ServerName>] sdset <ServiceName> <ServiceSecurityDescriptor>

The security descriptors in the syntax above are represented by what is known as "Security Descriptor Definition Language" (SDDL). An SDDL descriptor has it's own syntax and formatting conventions which, at first, may seem a bit intimidating, and I might add, somewhat bland. But we will just dwell on the elementary details that are relevant to our purpose. If you want to get into the nuances of the Language you can check out the resources referenced at the end of this post.

Before modifying the permissions to a service , it would be a good idea to view the permissions first. To do that run the following command:

sc SDSHOW "ColdFusion 2016 Application Server"

You can find out the name of the service from the service properties in the Services window. The output should be something similar to the following :


I'll break down the output above into subsections and try to describe them.


The prefix D is for discretionary access control list (DACL) permissions. it identifies users or groups that are allowed or denied access to a secured object.


The prefix S is for system access control list (SACL) which controls how access is audited. It enables administrators to log attempts to access a secured object in security event logs. This section is not pertinent to our interest, and hence will not be discussed further. 

Each segment enclosed by parentheses such as "(A;;CCLCSWRPWPDTLOCRRC;;;SY)", is an ACE or "Access Control Entry". It describes the permissions to a specific user or group.

The first letter in the ACE specifies the ACE type. 'A' here denotes "Allow". Similarly a 'D' would denote "Deny".

The next set of letters ("CCLCSWRPWPDTLOCRRC") denote the permissions. It is a combination of sets of 2 letters that specify the nature of permission. I'll list out the components below :

CC : SERVICE_QUERY_CONFIG – ask the SCM for the service’s current configuration

DC : Delete All Child Objects



RP : Read all properites

WP : Stop the service




SD : Delete

RC : READ_CONTROL – read the security descriptor on this service.

WD : Modify permissions

WO : Modify owner


The last code in ACE denotes the trustee. Some of the values it can take are:

SY : Local system

BU : Built-in users

IU : Interactively logged-on user

BA : Built-in administrators

If the intent is to modify the permission for a specific user and not a group, then you should rather use the SID associated with that user account. Suppose the ColdFusion Application service is running with a non-administrator account called "cfuser". To get the security identifier (SID) for "cfuser" account, you can execute the following WMIC command :

wmic useraccount where name='cfuser' get sid

That should output something similar to the following:



To enable start/stop permission for "cfuser" on ColdFusion Application service, you can use the output generated in the SDSHOW command and append an ACE element for "cfuser" with the desired permission set, as follows : 


And, of course, you should run the command with administrator privileges.

If you are using other ColdFusion services, such as ColdFusion Add-on Services, ColdFusion .NET Service, ODBC Agent and ODBC server, you can follow the same steps as above to change permissions to them.



2016-05-17 09:21:16
2016-05-17 09:21:16

@Piyush, sorry if there was confusion in my post…when I said the C: drive, I did not mean the root of C. As you mentioned, it tries to place it in the user folder which services accounts do not have. In our case, the service account only has access to the CF installation directory, nothing more. (Same behavior on CF10, 11, and 2016).

2016-05-17 07:05:12
2016-05-17 07:05:12

I don’t see the update files getting unpacked in the Windows root drive.
I tried the CF2016 Updater on Win 7 x64, it seems to be using the c:Users%username% drive, which I think is still incorrect since it should ideally be using the temp folder (%tmp%) of the logged-in user for that purpose.
Which version of ColdFusion are you on?

Thanks, Pete.
Those Windows command let you exercise a certain level of control on the permissions you are assigning to a trustee. Just wondering, can there be a potential security risks with the “RPWPCR” permission used in the example in this post.

2016-05-16 11:00:29
2016-05-16 11:00:29

@Pete thank you for the reminder.

2016-05-16 07:42:22
2016-05-16 07:42:22

@Steve – instead of temporarily switching CF to the System Account to run updates, you can instead just download the hotfix in CF Administrator, then open Command Prompt (as Administrator) and run:

java -jar path/to/hf-update/hotfix_0xx.jar

You might need to specify the full path to java.exe above if it says command not found. This approach is outlined in the Lockdown Guide, and has worked quite well for me since CF10.

@Adobe thanks for documenting this. I still prefer keeping the cfuser privileges minimal and installing updates from command line, but I think for some this might be useful.

2016-05-16 05:35:04
2016-05-16 05:35:04

The bigger problem is that the update files get unpacked on the C: drive and not within the installation folder of ColdFusion. In our environment, service accounts cannot logon to a machine and therefore do not have a user folder or permissions to write to the C drive. To run the updates, we have to switch to the system account, restart CF, apply the update, wait for CF to restart, change the logon back to the service account and restart CF.

Add Comment