0

the command:

test-path "\\someserver\c$\windows\ccm\logs\execmgr.log"

returns true when run from a console but false when run from ISE.

is there something I'm missing here? (the credentials executing this command has admin rights.)

the credential context under which I'm running both the Console and ISE are identical and have the highest elevation and I'm able to access that folder using the absolute path.

Fuzzy
  • 3,810
  • 2
  • 15
  • 33
  • **Need More Info:** Assuming the path is exactly what your testing with only the servername changed, right? Running as the same user from the same host? Are both ISE and console are elevated or not elevated (both in the same elevation status)? – VertigoRay Mar 16 '18 at 17:02
  • Might be relevant. ISE runs a different profile https://stackoverflow.com/questions/20022976/difference-between-powershell-console-and-powershell-ise – UnhandledExcepSean Mar 16 '18 at 17:39

2 Answers2

0

Assuming you're on the same computer using the same user ...

You're likely not authenticated/elevated the same to hit the share from the ISE. Try the following commands in both ISE and console. Any differences should lead you towards a solution...

  • & net use
  • Test-NetConnection 'someserver'
  • Test-Path '\\someserver\c$'
  • Test-Path '\\someserver\c$\windows'
  • Test-Path '\\someserver\c$\windows\ccm'
  • Test-Path '\\someserver\c$\windows\ccm\logs'

Update

In the ISE try authenticating the share with & net use \\someserver\c$.

VertigoRay
  • 5,935
  • 6
  • 39
  • 48
  • thanks for that the Test-NetConnection succeeded but the Test-Path failed from the ISE but from console both succeeded – Fuzzy Mar 16 '18 at 17:11
  • the credential context under which I'm running both the Console and ISE are identical and have the highest elevation and I'm able to access that folder using the absolute path. – Fuzzy Mar 16 '18 at 17:13
  • You're able to `cd '\\someserver\c$\windows\ccm\logs'` from the ISE? – VertigoRay Mar 16 '18 at 17:13
  • From console yes, from ISE no – Fuzzy Mar 16 '18 at 17:15
  • Very odd; ISE loads a slightly different dev environment, and I've heard of issues. However, I've never heard of one so simplistic. In the ISE try authenticating the share with `& net use \\someserver\c$`. – VertigoRay Mar 16 '18 at 17:17
  • yeah its strange behaviour – Fuzzy Mar 16 '18 at 17:19
  • Confirmed that I'm **not** getting the same issue on a domain joined client/server hitting the exact same path; as created by the CCM client. – VertigoRay Mar 16 '18 at 17:25
  • For what it is worth, I always suggest that people never use the ISE for development. Even MS suggests that you not. – EBGreen Mar 16 '18 at 17:30
  • I've been using the ISE since it's introduction and have never had anything that I needed fail. If I am running interactive command line code from the ISE I simply programmatically shell to the command to the console host and that returns me back to the ISE when done. – postanote Mar 16 '18 at 20:28
  • Also, though I've never needed to look for one. EBGreen, where is the TechNet/MSDN/MS Support doc(s) or MS Channel 9, MS Virtual Academy link that states that MS say don't use the ISE for development? I mean that is how the ISE was positioned until the advent of VSCode (which I use, as needed). – postanote Mar 16 '18 at 20:32
  • I don't have SC deployed in any of my labs. However, using the ISE as an domain admin or a user (group member or direct member) in the target host administrators group. I can hit, use, create, manage any default share C$, IPC$, or other created share on any other server. This is sounds environmental. Yet, still, I cannot fathom why the failure other session identity used in both. – postanote Mar 16 '18 at 20:49
  • thanks guys so it looks like it's security context related. So it runs under my user context and discovers the paths but not under the service account which has the highest rights. I have it working now for some of our servers but need to investigate further. – Fuzzy Mar 16 '18 at 21:16
0

Just ran into the same problem when trying to check a registry path. For example, Test-Path "HKLM:\SOFTWARE\Microsoft" returns true in both ISE and console. Test-Path "SOFTWARE\Microsoft\Microsoft Identity Extensions" yields true in console, but false in ISE. Both are executed under elevated privileges. Same with Get-ItemProperty - it does not find the registry path in ISE.

Finally I noticed that this problem only persists in ISE x86. In ISE x64, same cmdlets work perfectly fine. So my solution was to switch to ISE x64.

Alexander Drogin
  • 586
  • 3
  • 9