iisreset.exe access denied error via elevated CMD

iisreset.exe command when executed in normal command prompt will be needing admin privileges to restart the services related to IIS on a particular endpoint. 

On the admin command prompt it should not be causing any issue , it got the admin privileges to do so.

Do share a screenshot what you get while trying to use IISreset.exe , that will clear it more.

Another piece to consider is that when you run iisreset in an elevated command prompt, it is spawning a new process (iisreset.exe). What this means is that unless a.) process inheritance is enabled, or b.) we have an elevation rule specifically for iisreset, then you may still receive an Access Denied despite running it in an Administrator command prompt.

I’m able to replicate this issue if I elevate CMD but force IISRESET to run Passively:

I had actually created a separate definition just for the iisreset.exe with child process matching enabled but I am still getting the same Access Denied error. The iisreset was run in Admin mode CMD, same as Neil’s screenshot

Hey @Jasper,

I see you’ve raised a case for this, thank you for bringing this to our attention.

In the meantime, you may want to double-check and make sure your current Application Definition for iisreset.exe is in your standard “Add Admin” App Group, and not in the “Add Admin (On-Demand)” App Group.

The reason for this is because On-Demand application rules are applicable only for “Right Click → Run As Admin” process executions. When we’re launching iisreset.exe from CMD, this would be hitting your standard Application Rules, not On-Demand.

I hope this helps!

Hi @Neil , I have actually created a separate Add Admin-Medium Flexibility (On-Demand) application group which also contains the definition for the iisreset.exe, same as on the standard Add Admin-Medium Flexibility app group but it still does not get triggered. It just shows Access denied.
 

Thanks @Akshay Sharma , the full path did the trick. My definition did not include the full path. It is working now. I tested it and it fully stopped and restarted the service again.

Just to note, the full path isn’t explicitly required for this to work, we simply need to ensure that the characteristics we define within the Application Definition match the application we are attempting to target (and as Neil has noted above, that the application definition is defined in the rule set which matches the way we are invoking the application). 

Without reviewing more details, it is challenging to determine exactly why this did not work with your previous configuration, but assuming it simply used the product name ‘Internet Information Services’ I would expect IISreset.exe to have matched.

However (if only for the benefit of others), I also wanted to caution against using overly broad definitions such as Product Name (except perhaps during troubleshooting), especially in isolation and particularly when targeting applications for elevation.

One thing that I have found is that running IISReset from a remote server needs a rule high up in the workstyles because if it has too many rules it will cause the command to hang.  However, yes IIS has to have full admin token and a rule we have set up is that command prompt elevated also elevates child processes, so we also have a high level rule for passively launching IISReset for those users that want to run it from a remote server.