I
icelava
Guest
Yesterday I was fiddling with Azure Files service to check out its Internet-accessible SMB shared folder behaviour.
Mapping a drive letter with NET USE was simple enough. (although disturbed they don't offer a read-only access key, and must use full admin write access key) The significant thing though, is we're mapping a drive letter for NT AUTHORITY\SYSTEM context, done so via a scheduled task to run on system start. That works ok too.
However, now when I launch up PowerShell ISE, it's stuck forever at loading. Nothing can be done other than to kill powershell_ise.exe.
When I run a regular PowerShell shell, I see an error Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed
If I disconnect the drive letter than the problem goes away.
Thing is, previously, we were mapping the drive letter to an IIS WebDAV web server and didn't face any such problem. What sort of differences with Azure's public SMB server(s) can cause this limbo?
The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral
More...
Mapping a drive letter with NET USE was simple enough. (although disturbed they don't offer a read-only access key, and must use full admin write access key) The significant thing though, is we're mapping a drive letter for NT AUTHORITY\SYSTEM context, done so via a scheduled task to run on system start. That works ok too.
However, now when I launch up PowerShell ISE, it's stuck forever at loading. Nothing can be done other than to kill powershell_ise.exe.
When I run a regular PowerShell shell, I see an error Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed
If I disconnect the drive letter than the problem goes away.
Thing is, previously, we were mapping the drive letter to an IIS WebDAV web server and didn't face any such problem. What sort of differences with Azure's public SMB server(s) can cause this limbo?
The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral
More...
