This is an odd one out of left field. I have a local instance of PU running for development purposes, the service runs as local system. Using the PU extension in VSCode I haven’t been able to successfully attach the debugger to the process when using wait-debugger in my code. My understanding is that I need to run the PU service under my user account for this to work. And here comes the out of left field part:
My work laptop is an Entra ID joined device. I log in with my Entra ID user account. As such, even though my account is in the local admins group, it does not appear as a local account. So, I can’t set the PU service to run under my user creds. I tried running VSCode as admin but that didn’t work either. I am currently researching if there is a way to run the service as my Entra ID user. But no luck so far.
Am I out of luck here? Or have I completely misunderstood how the PU debugging works? All of the other VSCode extension integration works. Just the debugging fails. Basically, the process sits there in breakpoint mode and when I try to attach I get the error ‘powershell universal debugger detached’ and VSCode just sits in the debug mode doing nothing. I have to quit the debugger and then go into PU to kill the process to get it out of breakpoint mode.
Product: PowerShell Universal
Version: 4.2.17
Have you tried logging into your device with the service account (assuming you set it up to allow local logon - not deny it, as one usually would with a service account), to see if it proves the theory that it’s limited to just your AzureAD account?
There is no service account. The service is running as local system. i would have to create a new local user as the service account. Which is currently blocked by intune policy. Since the laptop is not domain joined you can’t access any domain accounts from the machine. it behaves like it is in a workgroup. Only Entra ID users can log in against Azure.
1 Like
I see. Have you already tried having the Intune admin allow you to make a local account (at least just to test whether it fixes the issue)? Seems like a rather easy solution if all they need to do is push a custom policy to your device that allows you to create a local account to use for things like this, since it appears to be a rather glaring shortcoming of using Azure AD (Entra ID).
I considered that. And I still might. I just wanted to poll the forum to see if anyone else had run into this before and if there was another solution. There are other impacts that cause issues as well. Since the machine is not domain joined, any scripts that try to modify data in AD fail without explicit credentials. This forces me to maintain two configurations for Apps. One on my local that uses explicit credentials, and one on my QA box that is using an AD service account that doesn’t require explicit credentials.
I have been using VSCode remote development to connect to VSCode on my QA box to get around this but debugging PU through a VSCode remote connection is problematic as well. The PU extension Remote connection doesn’t like my laptop configuration either. So that remote connectivity hasn’t been useful.
Basically, I am in a niche use case that I have to deal with. So, I guess I am out of luck on the debugging feature.