Powershell: mapped network drive disappear after reboot

Question

I need to create some kind of automated solution for re-mapping network drive with new credentials, but person who will be doing that can't know the credentials. For this I thought PowerShell script will be the best solution, so I wrote one below. Script is doing fine, everything is working as it should be BUT** mapped drive disappears after the reboot.** Do you know what should I do differently or something else to get this mapped drive persist?

Here is the script:

Net use * /delete /yes

$username = "domain\username"
$pwdFile = "$env:USERPROFILE\Desktop\xxx_mapping\fs_pwd.txt"
$keyFile = "$env:USERPROFILE\Desktop\xxx_mapping\AES.key"
$key = Get-Content $keyFile
$password = Get-Content $pwdFile | ConvertTo-SecureString -Key $key
$fs_path = "\\pathTo\Share"
$driveLetter = "P"
New-PSDrive -Name $driveLetter -PSProvider "FileSystem" -Root $fs_path -Credential (New-Object System.Management.Automation.PSCredential($username, $password)) -Persist

$filePath = "C:\Windows\someFile"
$fileContent = Get-Content -Path $filePath
foreach ($line in $fileContent) {
    if ($line -match "Path of the Remote Work Directory=(.*)") {
        $remoteWorkDirectory = $matches[1].Trim()
        $computerName = $env:COMPUTERNAME
        $outputString = "$remoteWorkDirectory-$computerName"
        Add-Content -Path "P:\evidenceFile.txt" -Value $outputString
    }
}

Remove-Item -Path "$env:USERPROFILE\Desktop\xxx_mapping" -Recurse

Code explanation:

1. I wanted to delete prevously mapped drives, so there is net use command
2. Password is secured in the file, so there you can see bunch of variables related to password
3. After completing mapping, as evidence line from the configuration file is copied to another file on the share drive
4. After all done, folder from the desktop is deleted

EDIT:

• -Scope Global, added to the script and unfortunately it's not solving the issue.

• I was trying to add this credentials to Windows Credential Manager using cmdkey but I think credentials are not stored properly (I mean password is incorrect) because mapping is not proceeding. When I used password without this encryption procedure it was working exactly how I wanted it to. But I can't use encrypted password in the script due to security policy. This is the code I used:

$username = "domain\username"
$pwdFile = "$env:USERPROFILE\Desktop\xxx_mapping\fs_pwd.txt"
$keyFile = "$env:USERPROFILE\Desktop\xxx_mapping\AES.key"
$key = Get-Content $keyFile
$password = Get-Content $pwdFile | ConvertTo-SecureString -Key $key
$serverName = "server"

cmdkey /add:$serverName /user:$username /pass:$password
net use p: \\server\share /persistent:yes

Answer 1

The documentation for New-PSDrive has this to say:

If you're running New-PSDrive inside a script, and you want the drive to persist indefinitely, you must dot-source the script. For best results, to force a new drive to persist indefinitely, add the Scope parameter to your command, and set its value to Global. For more information about dot-sourcing, see about_Scripts.

PSDrives are created in the scope in which the New-PSDrive command is run. When the command is run within a script, the drive mapping is local to the script. When the script exits, the drive is no longer available.

To ensure that the drive is available outside of the script you must use the Scope parameter to create the drive in the Global scope.

With that in mind, add the -scope global switch to your command:

New-PSDrive -Name $driveLetter -PSProvider "FileSystem" -Root $fs_path -Credential (New-Object System.Management.Automation.PSCredential($username, $password)) -Persist -Scope "Global"

Although, to be honest I doubt this will fix it. I find network mapping in Windows to be extremely temperamental, and most organisations opt to include a logon script with Group Policy that re-maps every required Network Drive for the user every time they log in.

You may already be aware but the method of mapping a network drive for a user using another account's credentials is not secure. While the password is encrypted, the decryption key is also stored where the user can view it so acquiring the password would be a trivial process. The obvious solution would be to grant the individual users access to the file-share, but presumably you are unable to do that in this situation.