See the below ---
Clear Windows Credential Cache
The utility to delete cached credentials is hard to find. It stores
both certificate data and also user passwords.
Open a command prompt, or enter the following in the run command
rundll32.exe keymgr.dll,KRShowKeyMgr
There is also a command-line utility:
C:\> cmdkey /?
Creates, displays, and deletes stored user names and passwords.
Drive mappings are just a pain historically. Well, you know... ;-}
Net use was not the only option, as you could use WScript in VBS or WMIC to do this as well. So, sure PowerShell can do WMI for this.
#PSTip Create mapped network drive using WScript.Network
An example of how a drive can be mapped can be seen here:
(New-Object -ComObject WScript.Network).MapNetworkDrive('Z:','\\server\folder')
This will not map the drive persistently. In other words, the drive
will disappear after reboot or when a user logs out. To ensure the
drive mapping is persistent a third argument should be added–a Boolean
value set to true:
(New-Object -ComObject WScript.Network).MapNetworkDrive('Z:','\\server\folder',$true)
Using the -persist switch is the PowerShell option for drive stickiness, but you also have the Smb cmdlets, since v3.
Get-Command -Name '*smb*'
CommandType Name Version Source
----------- ---- ------- ------
...
Function Get-SmbGlobalMapping 2.0.0.0 SmbShare
Function Get-SmbMapping 2.0.0.0 SmbShare
...
Function Get-SmbShare 2.0.0.0 SmbShare
Function Get-SmbShareAccess 2.0.0.0 SmbShare
....
Function New-SmbMapping 2.0.0.0 SmbShare
...
Function New-SmbShare 2.0.0.0 SmbShare
...
Function Remove-SmbShare 2.0.0.0 SmbShare
...
Function Set-SmbShare 2.0.0.0 SmbShare
...
See also:
Powershell: Map/Unmap Network drive on a remote computer
As for this...
I run it in powershell, but double clicking on the file to run it does
not map the drive, probably because of access issues.
… it's not a thing. .ps1 are by default associated with notepad or other text editor. This I by design. Sure, you can change that association, but don't. Users double click just about anything, and that can lead to a bunch of real issues security / risk management / operationally for you and your org.
There are ways to double click to run, with / without elevated permissions:
- The whole association thing, just don't do that.
- Call a .ps1 from a bat/ cmd file.
Though I really have always felt this, double click to run even for even .bat, .vbs, .cmd and they just run was a bad thing, well before PowerShell was a thing. Yet, industry got in to that habit and thus hard to get folks off of it.
- Create a custom shortcut, properly configured to double click to
run.
Example:
# specify the path to your PowerShell script
$ScriptPath = "C:\test\test.ps1"
# create a lnk file
$shortcutPath = [System.IO.Path]::ChangeExtension($ScriptPath, "lnk")
$filename = [System.IO.Path]::GetFileName($ScriptPath)
# create a new shortcut
$shell = New-Object -ComObject WScript.Shell
$scut = $shell.CreateShortcut($shortcutPath)
# launch the script with powershell.exe:
$scut.TargetPath = "powershell.exe"
# skip profile scripts and enable execution policy for this one call
# IMPORTANT: specify only the script file name, not the complete path
$scut.Arguments = "-noprofile -executionpolicy bypass -file ""$filename"""
# IMPORTANT: leave the working directory empty. This way, the
# shortcut uses relative paths
$scut.WorkingDirectory = ""
# optinally specify a nice icon
$scut.IconLocation = "$env:windir\system32\shell32.dll,162"
# save shortcut file
$scut.Save()
# open shortcut file in File Explorer
explorer.exe /select, $ShortcutPath
- Turn our script into an .exe using this MS PowerShellGallery.com
tool.
PS2EXE-GUI: "Convert" PowerShell Scripts to EXE Files with GUI
So, you have options. Which you choose is a matter of operational allowances, etc.