CODEWITHSUNDEEP
powershellazureazure-powershelldsc
227Passive
227Passive

Reputation: 33

Drive Mapping with Azure Scale Sets using Desired State Configuration

I am running into an interesting issue. Maybe you fine folks can help me understand what's happening here. If there's a better method, I'm all ears.

I am running a DSC Configuration on Azure and would like to map a drive. I've read this really isn't what DSC is for, but I am not aware of any other way of doing this outside of DSC with Azure Scalesets. Here's the portion of the script I am running into issues:

Script MappedDrive
    {
        SetScript = 
        {
        $pass = "passwordhere" | ConvertTo-SecureString -AsPlainText -force
        $user = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "username",$pass
        New-PSDrive -Name W -PSProvider FileSystem -root \\azurestorage.file.core.windows.net\storage -Credential $user -Persist
        }
        TestScript = 
        {
            Test-Path -path "W:"
        }
        GetScript = 
        {
        $hashresults = @{}
        $hashresults['Exists'] = test-path W:
        }
    }

I've also attempted this code in the SetScript section:

(New-Object -ComObject WScript.Network).MapNetworkDrive('W:','\\azurestorage.file.core.windows.net\storage',$true,'username','passwordhere')

I've also tried a simple net use command to map the drive instead of the fancy, New-Object or New-PSDrive cmdlets. Same behavior.

If I run these commands (New-Object/Net Use/New-PSDrive) manually, the machine will map the drive if I run it with a separate drive letter. Somehow, the drive is attempting to be mapped but isn't mapping.

Troubleshooting I've done:

Upvotes: 1

Views: 3035

Answers (2)

CodedBeard
CodedBeard

Reputation: 912

I had a similar problem before, while it didn't involve DSC, mounting an Azure File share would be fine until the server would be restarted, then it would appear as a disconnected drive. This happend if i used New-Object/Net Use/New-PSDrive with the persist option.

The answer to that issue, i found in the updated docs

Persist your storage account credentials for the virtual machine

Before mounting to the file share, first persist your storage account credentials on the virtual machine. This step allows Windows to automatically reconnect to the file share when the virtual machine reboots. To persist your account credentials, run the cmdkey command from the PowerShell window on the virtual machine. Replace with the name of your storage account, and with your storage account key.

cmdkey /add:<storage-account-name>.file.core.windows.net /user:<storage-account-name> /pass:<storage-account-key>

Windows will now reconnect to your file share when the virtual machine reboots. You can verify that the share has been reconnected by running the net use command from a PowerShell window.

Note that credentials are persisted only in the context in which cmdkey runs. If you are developing an application that runs as a service, you will need to persist your credentials in that context as well.

Mount the file share using the persisted credentials

Once you have a remote connection to the virtual machine, you can run the net use command to mount the file share, using the following syntax. Replace with the name of your storage account, and with the name of your File storage share.

net use <drive-letter>: \\<storage-account-name>.file.core.windows.net\<share-name> example : net use z: \\samples.file.core.windows.net\logs

Since you persisted your storage account credentials in the previous step, you do not need to provide them with the net use command. If you have not already persisted your credentials, then include them as a parameter passed to the net use command, as shown in the following example.

Edit: I don't have an Azure VM free to test it on, but this works fine on a Server 2016 hyper-v vm

Script MapAzureShare
    {
        GetScript = 
        {

        }
        TestScript = 
        {
            Test-Path W:
        }
        SetScript = 
        {
            Invoke-Expression -Command "cmdkey /add:somestorage.file.core.windows.net /user:somestorage /pass:somekey"
            Invoke-Expression -Command "net use W: \\somestorage.file.core.windows.net\someshare"
        }
        PsDscRunAsCredential = $credential
    }

In my brief testing the drive would only appear after the server was rebooted.

Upvotes: 2

4c74356b41
4c74356b41

Reputation: 72191

What I imagine is happening here:
DSC runs under the NT AUTHORITY\SYSTEM account and unless the Credential attribute has been set, the Computer account is used when pulling the files from a network share. But looking at how Azure Files operate, permissions shouldn't be an issue, but running this whole process under NT AUTHORITY\SYSTEM could. I suggest you try to run DSC as a user of your VM's and see if that works.

ps. You could also try to perform the same operation against a VM with network share where you are confident that share\ntfs permissions are correct. You might need to enable anonymous user to access your share for that to work.

Upvotes: 0

Related Questions