Help with running control panel applet

I am getting an issue when I try to run the below command on a system I am not an admin on. The message I get when I run the code is below. I am not sure how to get around the issue.

Appwiz.cpl

Start-Process -Credential LocalAdmin -FilePath "powershell" -argumentlist '-command &{Start-process appwiz.cpl}'

Just an FYI, your code ran fine on my system, no issues.

Does the user LocalAdmin exists on that computer? And you need to know the admin credentials … you know that, don’t you?

Yes the account in question is on all systems and the password is known. The message only appears after the PowerShell window closes.

That raises actually more questions than it answers. :thinking: :face_with_hand_over_mouth:

What is it, what you’re actually trying to do?

Did you try to create a credential object beforehand with Get-Credential and use this instead of the user name LocalAdmin?

The command is to be part of a script to open control panel applets as the local administrator account. We did not try using get-credential only because start-process allows for prompting the user for credentials and the username to be used is the same on all machines that this could be used on.

OK, but why or whatfor? And if the users have the credentials/password why can’t they open the control panel on their own?

And since …

Could the error message be caused by another piece of your code?

The end user does not have the password to the account only IT does. This is the only piece of code so far. Eventually the control panel applet will change due to an IT user selection but that part has not been written yet.

I’m trying to follow but I’m more confused than ever.

You said this

Then you said this directly after

So you want to prompt the user for the password but the user doesn’t have the password?

I’m on the same page as Doug … what you wrote so far is quite confusing …

:man_shrugging:t3:

What is actual goal of all this? … and please don’t answer “to open the control panel as admin” … :smirk:

If this should be a way to give a user with no admin privileges the ability to perform admin tasks, I highly recommend to reconsider this approach.

And again … since …

It might be an issue with your environment. :wink: :man_shrugging:t3:

If your IT personell is about to run this script why not starting it elevated from the start? Then you don’t have to tinker around with some quirky tricks to gain admin privileges. :man_shrugging:t3:

Hi tbingeman,

Sorry for the long reply, but I think you’ll find some value in it…

I’m going to assume that you are looking to run a PowerShell script on a User’s system remotely… and while they (a non-admin) are logged in? From an IT standpoint, it’s best to login locally or remotely using your domain admin credentials to manage the system.

I’m not going to berate you about how the secure desktop (User Account Control) works because I can only assume you are very familiar with it. However, when it comes to scripting, it’s important to remember that all Elevated Permissions will go through the secure desktop for any program/process to truly be running with elevated permissions.

The easiest way to remember when a script might work is: No shield = No UAC, which in turn = no admin rights.
Your script is using a Run as different user method (no shield) and not Run as Administrator (shield).

Although you are using the -Credential switch and prepopulating the username - LocalAdmin - in your case, this only opens a credential request window - tied to the Credential Manager which is not an Admin feature. All of the Control Panel applets are in the system32 folder, so all will get you a UAC prompt… even when you’re logged in as an Admin (which I call a consent prompt yes/no).

I’ll share three examples that may help shine some light on why you can’t normally bypass the secure desktop to get elevated permissions:

I’m going to open three PowerShell sessions using three different methods:

  1. Standard User (no shield)
  2. Run as different user using local Administrator account (no shield; no UAC prompt)
  3. Run as Administrator (shield + UAC prompt)

I performed the following tasks in each PowerShell session in order:

Write-Host $env:USERPROFILE to show which profile is running that PowerShell session

  1. A standard user test account
  2. The built-in Administrator account
  3. The built-in Administrator account

Disabling a network adapter requires admin permissions. I tried disabling IPv6 on Ehternet0:

  1. Standard User got access is denied… as expected (no shield)
  2. Administrator got Access is denied… this is the Run as different user (no shield)
  3. Administrator was successful and verified results; this is the Run as Administrator session (shield)

The last test is opening Programs and Features using appwiz.cpl

  1. Standard User: opened successfully but gets a UAC prompt trying to uninstall a program
  2. Administrator: this one failed to open and throws up that same error you reported in your initial post
  3. Administrator: opened successfully but gets a UAC prompt trying to uninstall a program (expected)

I hope this helps shed some light on what you’re up against. I just don’t think there is a script that’s going to get you past the UAC without first modifying the UAC settings on all of the system in your organization…

The PLUS SIDE :+1:t2:

Login with your admin credentials and your scripts will make your job a lot easier… including the ones that need to run with elevated permissions. Then all you have to do is click Yes and let it run… while you take a coffee break! :slight_smile: