Сопоставление дисков с масштабируемыми наборами Azure с использованием конфигурации требуемого состояния

Возникла интересная проблема. Может быть, вы, добрые люди, поможете мне понять, что здесь происходит. Если есть способ получше, я весь уши.

Я использую конфигурацию DSC в Azure и хочу подключить диск. Я читал, что DSC действительно не для этого, но я не знаю других способов сделать это за пределами DSC с помощью масштабируемых наборов Azure. Вот часть сценария, с которой я столкнулся с проблемами:

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:
        }
    }

Я также пробовал этот код в разделе SetScript:

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

Я также пробовал простую команду net use для сопоставления диска вместо причудливых командлетов New-Object или New-PSDrive. Такое же поведение.

Если я запустил эти команды (New-Object / Net Use / New-PSDrive) вручную, машина подключит диск, если я запущу его с отдельной буквой диска. Каким-то образом диск пытается подключиться, но не отображается.

Устранение неполадок, которые я сделал:

  • В моей среде нет домена. Я просто пытаюсь создать масштабируемый набор и запустить DSC для настройки машины с использованием учетных данных учетной записи хранения, предоставленных при создании учетной записи хранения.
  • Я использую имя пользователя и пароль, предоставленные мне идентификатором пользователя учетной записи хранения и ключом доступа (случайно сгенерированный ключ, обычно с именем учетной записи хранения в качестве пользователя).
  • Azure не выдает ошибок при запуске модуля DSC (нет ошибок в журнале событий, только информация - последовательность выполнения ресурсов правильно перечисляет все мои последовательности в файле DSC).
  • Когда я вхожу в систему и проверяю, сопоставлен ли диск, я сталкиваюсь с отключенным сетевым диском с буквой диска, которую я хочу (W :).
  • Если я открываю Powershell, я получаю сообщение об ошибке: «Попытка выполнить операцию InitializeDefaultDrives для поставщика FileSystem не удалась».
  • Если я запускаю «Get-PSDrive», диск W: не появляется.
  • Если я запускаю код SetScript вручную в консоли Powershell, подключенный диск отлично работает под другой буквой диска.
  • Если я попытаюсь отключить диск W :, я получаю сообщение «Это сетевое соединение не существует».
  • Я подумал, что, возможно, DSC нужно некоторое время перед сопоставлением и добавил таймер сна, но это не сработало. Такое же поведение.

person 227Passive    schedule 08.12.2016    source источник


Ответы (2)


Раньше у меня была аналогичная проблема, хотя она и не включала DSC, подключение файлового ресурса Azure было бы нормально, пока сервер не будет перезапущен, а затем он будет отображаться как отключенный диск. Это случилось, если я использовал New-Object / Net Use / New-PSDrive с опцией persist.

Ответ на этот вопрос я нашел в обновленные документы

Сохраните учетные данные своей учетной записи хранения для виртуальной машины

Перед подключением к общему файловому ресурсу сначала сохраните учетные данные своей учетной записи хранения на виртуальной машине. Этот шаг позволяет Windows автоматически повторно подключаться к общему файловому ресурсу при перезагрузке виртуальной машины. Чтобы сохранить учетные данные своей учетной записи, запустите команду cmdkey из окна PowerShell на виртуальной машине. Замените именем своей учетной записи хранения и ключом учетной записи хранения.

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

Windows теперь повторно подключится к вашему файловому ресурсу при перезагрузке виртуальной машины. Вы можете убедиться, что общий ресурс был повторно подключен, запустив команду net use из окна PowerShell.

Обратите внимание, что учетные данные сохраняются только в контексте, в котором запускается cmdkey. Если вы разрабатываете приложение, которое работает как служба, вам также необходимо сохранить свои учетные данные в этом контексте.

Подключите общий файловый ресурс, используя сохраненные учетные данные

После того, как у вас будет удаленное подключение к виртуальной машине, вы можете запустить команду net use для монтирования общего файлового ресурса, используя следующий синтаксис. Замените именем вашей учетной записи хранения и именем вашего общего хранилища файлов.

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

Поскольку вы сохранили учетные данные своей учетной записи хранения на предыдущем шаге, вам не нужно предоставлять их с помощью команды net use. Если вы еще не сохранили свои учетные данные, включите их в качестве параметра, переданного команде net use, как показано в следующем примере.

Изменить: у меня нет виртуальной машины Azure, на которой можно было бы ее протестировать, но она отлично работает на Hyper-v vm Server 2016.

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
    }

В моем кратком тестировании диск появлялся только после перезагрузки сервера.

person CodedBeard    schedule 08.12.2016
comment
На самом деле это приводит к ошибке. [[Script] MappedDrive] Выполнение операции Set-TargetResource на целевом объекте. Выполнение SetScript с предоставленными пользователем учетными данными. VERBOSE: [2016-12-09T14: 51: 06] [ERROR] Произошла системная ошибка 1312. VERBOSE: [2016-12-09T14: 51: 06] [ОШИБКА] Указанный сеанс входа в систему не существует. Возможно, он уже был прекращен. - person 227Passive; 09.12.2016
comment
Вы использовали PsDscRunAsCredential? cmdkey без него работать не будет. - person TravisEz13; 28.12.2016
comment
"PsDscRunAsCredential" недействителен. Если я использую Credtial вместо этого, cmdkey никогда не получит пользователя, которому я передаю результаты. Боюсь, это невозможно, как в powershell.org / форумы / тема / - person guillem; 12.07.2017

Я предполагаю, что здесь происходит:
DSC работает под учетной записью NT AUTHORITY\SYSTEM, и если атрибут Credential не был установлен, Computer account используется при извлечении файлов из общего сетевого ресурса. Но если посмотреть, как работают файлы Azure, разрешения не должны быть проблемой, но запуск всего этого процесса под NT AUTHORITY\SYSTEM может. Я предлагаю вам попробовать запустить DSC как пользователь вашей виртуальной машины и посмотрим, работает ли это.

пс. Вы также можете попробовать выполнить ту же операцию с виртуальной машиной с сетевым ресурсом, если вы уверены, что разрешения share \ ntfs верны. Возможно, вам потребуется включить анонимный пользователь, чтобы получить доступ к вашей общей папке, чтобы это работало.

person 4c74356b41    schedule 08.12.2016
comment
Помните, что это не стандартная акция. Этот общий ресурс создается с использованием общего хранилища файлов Azure. Общий ресурс создается с помощью портала Azure и / или командлетов Powershell. Вы не изменяете разрешения пользователей, как обычные общие ресурсы на сервере Windows. - person 227Passive; 09.12.2016
comment
Я нигде в своем ответе не говорил об изменении разрешения, пожалуйста, прочтите перед тем, как комментировать. @ 227Пассивный - person 4c74356b41; 09.12.2016