Command execution failed: The process does not possess the ‘SeSecurityPrivilege’ privilege which is required for this operation

Error:- You try to Request and Install Lync server Certificate using deployment wizard and get the below error while assigning the certificate to Web Services Internal, External and Default and get below error

Command execution failed: The process does not possess the ‘SeSecurityPrivilege’ privilege which is required for this operation

Cause:- The reason is you do not have appropriate access to assign the certificate to given lync services.

Other Information:- Open GPEDIT.MSC in the lync server and go to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment

Check the setting “Manage Auditing and Security Logs”, you will see Local Administrators Group missing here.

Solution:- Add local Administrators group here locally or using Group Policy, run gpupdate /force, logoff user and relogin and try again.

Deployment Checker Script for Azure Stack Development Kit

<#
.SYNOPSIS
Short description
This prechecker script validates the hardware and software requirements of your host to prepare for the deployment of the Azure Stack Development Kit
.DESCRIPTION
The script provides a way to confirm the host meets the hardware and software requirements, before downloading the larger package for the Azure Stack Development Kit.
.EXAMPLE
.\asdk-prechecker.ps1
.NOTES
To use this script on the host where Azure Stack Development Kit will be installed, you need to run it as an administrator (the script will check if it is running in this context).
You may also need to update the PowerShell script execution policy with Set-ExecutionPolicy, since the script is not signed : https://technet.microsoft.com/en-us/library/hh849812.aspx
The Azure Stack Development Kit Pre-Checker script is a PowerShell script published in this public repository so you can make improvements to it by submitting a pull request.
https://github.com/Azure/AzureStack-Tools
#>
#requires –runasadministrator
function CheckNestedVirtualization {
    write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking for physical/virtual machine status…”
    $BaseBoard = (Get-WmiObject Win32_BaseBoard)
If ($BaseBoard)
{
If (($BaseBoard.Manufacturer.Tolower() -match ‘microsoft’ -and $BaseBoard.Product.Tolower() -match ‘virtual’) -or ($BaseBoard.Manufacturer.Tolower() -match ‘vmware’))
{
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — WARNING : This server seems to be a virtual machine running on Hyper-V or VMware. Running ASDK on a nested hypervisor is not a tested or supported scenario. Setup will not block this, but this but this may lead to performance or reliability issues.”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — This is a physical machine.”
$Global:ChecksSuccess++
}
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — This is a physical machine.”
$Global:ChecksSuccess++
}
}
function CheckInternetAccess {
write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking Internet access…”
    # Test AAD http connection.
try {
$resp = Invoke-WebRequest -Uri “https://login.windows.net” -UseBasicParsing
if ($resp.StatusCode -ne 200) {
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — Failed to connect to AAD endpoint https://login.windows.net”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — This machine has internet access (we tried to contact https://login.windows.net).”
$Global:ChecksSuccess++
}
}
catch {
write-host -ForegroundColor white “[“(date -format “HH:mm:ss”)”]” $_.Exception.Message
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — Failed to connect to AAD endpoint ‘https://login.windows.net’.”
$Global:ChecksFailure++
}
}
function CheckSystemDisk {
write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking system disk capacity…”
    $systemDisk = Get-Disk | ? {$_.IsSystem -eq $true}
If ($systemDisk.Size -lt 180 * 1024 * 1024 * 1024)
{
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — Check system disk failed – Size should be 180 GB minimum.”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — Check system disk passed successfully.”
$Global:ChecksSuccess++
}
}
function CheckDisks {
write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking physical disks…”

write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” ” — Listing of all physical disks on this server:”
write-host -ForegroundColor gray (Get-PhysicalDisk | Format-Table -Property @(“FriendlyName”, “SerialNumber”, “CanPool”, “BusType”, “OperationalStatus”, “HealthStatus”, “Usage”, “Size”) | Out-String)
$physicalDisks = Get-PhysicalDisk | Where-Object { ($_.BusType -eq ‘RAID’ -or $_.BusType -eq ‘SAS’ -or $_.BusType -eq ‘SATA’) -and $_.Size -gt 135 * 1024 * 1024 * 1024 }
$selectedDisks = $physicalDisks | Group-Object -Property BusType | Sort-Object -Property Count -Descending | Select-Object -First 1

    if ($selectedDisks.Count -ge 3) {
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” ” — Listing of all physical disks meeting ASDK requirements:”
write-host -ForegroundColor gray ($physicalDisks | Format-Table -Property @(“FriendlyName”, “SerialNumber”, “BusType”, “OperationalStatus”, “HealthStatus”, “Usage”, “Size”) | Out-String)
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — Check physical disks passed successfully. Note that ASDK handles situations where there is a pre-existing storage pool, and will delete/recreate it.”
$Global:ChecksSuccess++
}
    if ($selectedDisks.Count -lt 3) {
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — Check physical disks failed – At least 4 disks or more of the same bus type (RAID/SAS/SATA), and of capacity 135 GB or higher are strongly recommended. 3-disk configurations may work but are not tested by Microsoft.”
$Global:ChecksFailure++
}
}
function CheckFreeSpaceForExtraction {
    write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” ” Checking free space for extracting the ASDK files…”
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” ” — Listing disks and their free space”
write-host -ForegroundColor gray (Get-Disk | Get-Partition | Get-Volume | Sort-Object -Property SizeRemaining -Descending | Out-String)
$volumes = (Get-disk | ? {$_.BusType -ne ‘File Backed Virtual’ -or $_.IsBoot} | Get-Partition | Get-Volume |`
? {-not [String]::IsNullOrEmpty($_.DriveLetter)} | sort -Property SizeRemaining -Descending)
if (!$volumes -or ($volumes | Measure-Object).count -le 0) {
Write-Host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — Free space check failed. No volumes are available.”
$Global:ChecksFailure++
}
if ($volumes[0].SizeRemaining -lt 120 * 1024 * 1024 * 1024) {
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — Free space check failed. ASDK requires 130 GB for the expanded Cloudbuilder.vhdx file. An additional 40 GB may be needed if you want to keep the ZIP and self extractor files.”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — Free space check passed successfully.”
$Global:ChecksSuccess++
}
}
function CheckRam {
write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking Memory…”

$mem = Get-WmiObject -Class Win32_ComputerSystem
$totalMemoryInGB = [Math]::Round($mem.TotalPhysicalMemory / (1024 * 1024 * 1024))
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” ” — Memory on this server = $totalMemoryInGB”
if ($totalMemoryInGB -lt 96) {
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — Check system memory requirement failed. At least 96GB physical memory is required.”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — System memory check passed successfully. ASDK requires a minimum of 96 GB of RAM, with 128 GB recommended.”
$Global:ChecksSuccess++
}
}

function CheckHyperVSupport {
write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking Hyper-V support on the host…”
    $feature = Get-WindowsFeature -Name “Hyper-V”
if ($feature.InstallState -ne “Installed”) {
$cpu = Get-WmiObject -Class WIN32_PROCESSOR
$os = Get-WmiObject -Class Win32_OperatingSystem
if (($cpu.VirtualizationFirmwareEnabled -contains $false) -or ($cpu.SecondLevelAddressTranslationExtensions -contains $false) -or ($cpu.VMMonitorModeExtensions -contains $false) -or ($os.DataExecutionPrevention_Available -eq $false)) {
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — Hyper-V is not supported on this host. Hardware virtualization is required for Hyper-V.”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — This server supports the hardware virtualization required to enable Hyper-V.”
$Global:ChecksSuccess++
}
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — Hyper-V is already installed. Note that the installer would enable it otherwise.”
$Global:ChecksSuccess++
}
}
function CheckOSVersion {

# Check Host OS version first, otherwist DISM will failed to get VHD OS version
write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking Host OS version…”
$hostOS = Get-WmiObject win32_operatingsystem
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” (” — Host OS version: {0}, SKU: {1}” -f $hostOS.Version, $hostOS.OperatingSystemSKU)
$hostOSVersion = [Version]::Parse($hostOS.Version)

$server2016OSVersionRequired = “10.0.14393”
$server2016OSVersion = [Version]::Parse($server2016OSVersionRequired)
$serverDataCenterSku = 8 # Server Datacenter
$serverDataCenterEvalSku = 80 # Server Datacenter EVal

if ($hostOSVersion -lt $server2016OSVersion -or ($hostOS.OperatingSystemSKU -ne $serverDataCenterSku -and $hostOS.OperatingSystemSKU -ne $serverDataCenterEvalSku)) {
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — The host OS should be Windows Server 2016 Datacenter, version $server2016OSVersionRequired.”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — The host OS version matches the requirements for ASDK ($server2016OSVersionRequired).”
$Global:ChecksSuccess++
}
}

function CheckDomainJoinStatus {
write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking domain join status…”
    $sysInfo = Get-WmiObject -Class Win32_ComputerSystem
if ($sysInfo.PartOfDomain) {
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — The host must not be domain joined. Please leave the domain and try again.”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — The host is not domain joined.”
$Global:ChecksSuccess++
}
}
function CheckVMSwitch {
    write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking NIC status…”
    if (([array](Get-NetAdapter | ? {$_.Status -eq ‘Up’})).Count -ne 1) {
write-host -ForegroundColor darkyellow “[“(date -format “HH:mm:ss”)”]” ” — Multiple NICs, virtual switches or NIC teaming are not allowed. Please only keep one physical NIC enabled and remove virtual switches or NIC teaming. This message can be ignored if you are planning to leverage the ASDK Installer from GitHub, as it provides a way to configure the NICs.”
$Global:ChecksSuccess++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — NIC configuration passed successfully.”
$Global:ChecksSuccess++
}
}
function CheckServerName {
    write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking server name…”
    write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” ” — Server name is” $Env:COMPUTERNAME
  if ($Env:COMPUTERNAME -eq ‘AzureStack’) {
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — Server name cannot be “”AzureStack”” since it conflicts with the domain name.”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — Server name does not conflict with future domain name AzureStack.local.”
$Global:ChecksSuccess++
}
}
function CheckCPU {
    write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking processor information…”
    $CPUCount = (Get-WmiObject -class win32_processor –computername localhost).count
$CoreCount =  ((Get-WmiObject -class win32_processor –computername localhost -Property “numberOfCores”)[0].numberOfCores)*$CPUCount
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” ” — Number of CPU sockets = $CPUCount”
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” ” — Number of physical cores =  $CoreCount”
    If (($CPUCount -lt 2) -or ($CoreCount -lt 12)){
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — CPU count must be 2 or higher, Core count must be 12 or higher (16 cores recommended).”
$Global:ChecksFailure++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — CPU socket count (2) and core count (12) meet the minimum requirements for ASDK.”
$Global:ChecksSuccess++
}
}
function CheckNICSupport {
    write-host -ForegroundColor yellow “[“(date -format “HH:mm:ss”)”]” “Checking NIC requirements…”
    $FoundNIC = $false
Get-NetAdapter -IncludeHidden | ForEach-Object {
$PnPDevice = Get-PnpDevice -InstanceId $_.PnPDeviceID
If ((Get-PnpDeviceProperty -InputObject $PnPDevice -KeyName DEVPKEY_Device_DriverInfPath).Data -eq “netbxnda.inf”){
$FoundNIC = $true
}
}
   If ($FoundNIC)
{
write-host -ForegroundColor darkyellow “[“(date -format “HH:mm:ss”)”]” ” — Please make sure to leverage the ASDK Installer for deployment, per the documentation. This installer will apply an update to this host prior to deployment.”
$Global:ChecksSuccess++
}
else
{
write-host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” ” — Network cards requirements are met.”
$Global:ChecksSuccess++
}
}
$ErrorActionPreference = ‘Stop’
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” “Starting Deployment Checker for Microsoft Azure Stack Development Kit (ASDK)…”
Write-Host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” “There are several prerequisites checks to verify that your machine meets all the minimum requirements for deploying ASDK.”
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” “For more details, please refer to the online requirements : https://azure.microsoft.com/en-us/documentation/articles/azure-stack-deploy/”
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” “Checking for Administrator priviledge…”
if (-not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole(`
[Security.Principal.WindowsBuiltInRole] “Administrator”))
{
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” ” — You do not have Administrator rights to run this script!`nPlease re-run this script as an Administrator!”
break
}
$checksHW = {CheckNestedVirtualization}, `
{CheckSystemDisk},
{CheckDisks},
{CheckRam}, `
{CheckCPU},
{CheckHyperVSupport}`
$CheckHWOnly = {CheckFreeSpaceForExtraction}
$checksSW = {CheckDomainJoinStatus}, `
{CheckInternetAccess}, `
{CheckOSVersion}, `
{CheckVMSwitch}, `
{CheckNICSupport},
{CheckServerName}
$Global:ChecksSuccess = 0
$Global:ChecksFailure = 0
#Checking if ASDK is already installed
$POCInstalledOrFailedPreviousInstall = $false
If ((get-module -Name Hyper-V -ListAvailable).count -gt 0)
{
$VMList = @(“MAS-ACS01″,”MAS-ADFS01″,”MAS-ASql01″,”MAS-BGPNAT01″,”MAS-CA01″,”MAS-Con01″,”MAS-DC01″,”MAS-Gwy01″,”MAS-NC01”, “MAS-SLB01”, “MAS-SUS01”, “MAS-WAS01”, “MAS-Xrp01”, “AzS-ACS01″,”AzS-ADFS01″,”AzS-ASql01″,”AzS-BGPNAT01″,”AzS-CA01″,”AzS-Con01″,”AzS-DC01″,”AzS-Gwy01″,”AzS-NC01”, “AzS-SLB01”, “AzS-SUS01”, “AzS-WAS01”, “AzS-Xrp01”)
If ((Get-VM $VMList -ErrorAction SilentlyContinue).Count -gt 0)
{$POCInstalledOrFailedPreviousInstall = $true}
}
If ($POCInstalledOrFailedPreviousInstall)
{
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”] This machine seems to host an existing successful or failed installation of Azure Stack Development Kit. The prerequisite checker is meant to be run prior to installation, and will return errors post-install, as some of the configuration may already have been applied (joining the domain, setting up storage pools,…)”
If ((Read-Host “Do you want to continue anyway (Y/N)?”) -eq “N”)
{
break
}
}
write-host -ForegroundColor white “[“(date -format “HH:mm:ss”)”] This script can be run on the host where you will be configuring boot from VHD, for example prior to downloading the ASDK files. Or it can be run after booting from the provided Cloudbuilder.vhdx file where the ASDK will be installed. In the first case, it will only check for hardware specifications like memory, cores, hard disk configuration, as well as free space for extracting the ASDK files. In the second case, it will run both hardware and software tests, and other items like domain membership, OS version, NIC configuration will be checked.”
Switch (Read-Host “Are you running this script on the host before booting in the provider VHDX file [1] or after booting into it [2] (any other input will exit the script)?”)
{
“1”
{
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” “User chose to run pre-boot from VHD checks (hardware checks only)”
$checks = $checksHW + $CheckHWOnly
}
“2”
{
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” “User chose to run post-boot from VHD checks (all checks except free space)”
$checks = $checksHW + $checksSW
}
Default
{
write-host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” “User did not pick one of the two options, exiting script…”
exit
}
}
$PreCheckProgressMessage = “Running Prerequisites Check”
for($i=0; $i -lt $checks.Length; $i++)
{
Write-Progress -Activity $PreCheckProgressMessage -PercentComplete ($i * 100 / $checks.Length)
Invoke-Command -ScriptBlock $checks[$i] -NoNewScope
}
Write-Progress -Activity $PreCheckProgressMessage -Completed
If ($Global:ChecksSuccess -eq $Checks.Length)
{
Write-Host -ForegroundColor green “[“(date -format “HH:mm:ss”)”]” “SUCCESS : All of the prerequisite checks passed.”
}
else
{
Write-Host -ForegroundColor red “[“(date -format “HH:mm:ss”)”]” “FAILURE:”$ChecksFailure “prerequisite check(s) failed out of” $Checks.Length “. Please review previous entries to understand where the requirements are not met.”
}
write-host -ForegroundColor gray “[“(date -format “HH:mm:ss”)”]” “Deployment Checker has finished checking Azure Stack Development Kit requirements”

Install the Azure Stack Development Kit (ASDK)

Install the ASDK

The steps in this article show you how to deploy the ASDK using a graphical user interface (GUI) provided by downloading and running the asdk-installer.ps1 PowerShell script.

  1. After the host computer successfully boots into the CloudBuilder.vhdx image, log in using the administrator credentials specified when you prepared the development kit host computer for ASDK installation. This should be the same as the development kit host local administrator credentials.

  2. Open an elevated PowerShell console and run the <drive letter>\AzureStack_Installer\asdk-installer.ps1PowerShell script. Note that the script might now be on a different drive than C:\ in the CloudBuilder.vhdx image. Click Install.

3. In the Identity Provider Type drop-down box, select Azure China Cloud, Azure US Government Cloud, AD FS, or Azure Cloud. Under Local Administrator Password type the local administrator password (which must match the current configured local administrator password) in the Password box, and then click Next.

If you choose an Azure subscription identity provider, you need an internet connection, the full name of an Azure AD directory tenant in the form of domainname.onmicrosoft.com or an Azure AD verified custom domain name, and global admin credentials for the specified directory.

After deployment, Azure Active Directory global administrator permission is not required. However, some operations may require the global administrator credential. For example, a resource provider installer script or a new feature requiring a permission to be granted. You can either temporarily re-instate the account’s global administrator permissions or use a separate global administrator account that is an owner of the default provider subscription.
When using AD FS as the identity provider, the default stamp directory service is used. The default account to sign in with is azurestackadmin@azurestack.local, and the password to use is the one you provided as part of setup.

4. Select a network adapter to use for the development kit and then click Next.

5. On the Network Configuration page, provide a valid Time server IP address. This required field sets the time server to be used by the development kit. This parameter must be provided as a valid time server IP address. Server names are not supported.

Optionally, you can provide a DNS forwarder IP address. A DNS server is created as part of the Azure Stack deployment. To allow computers inside the solution to resolve names outside of the stamp, provide your existing infrastructure DNS server. The in-stamp DNS server forwards unknown name resolution requests to this server.

6. On the Verifying network interface card properties page, you’ll see a progress bar. When verification is complete, click Next.

7. On Summary page, click Deploy to start ASDK installation on the development kit host computer.

8. If you’re performing an Azure AD deployment, you’ll be prompted to enter your Azure AD global administrator account credentials a few minutes after setup starts

9. The deployment process will take a few hours, during which time the host computer will automatically reboot once. If you want to monitor the deployment progress, sign in as azurestack\AzureStackAdmin after the development kit host restarts. When the deployment succeeds, the PowerShell console displays: COMPLETE: Action ‘Deployment’.

Congratulations, you’ve successfully installed the ASDK!

If the deployment fails for some reason, you can redeploy from scratch or use the following PowerShell commands, from the same elevated PowerShell window, to restart the deployment from the last successful step:

cd C:\CloudDeployment\Setup
.\InstallAzureStackPOC.ps1 –Rerun

Prepare the ASDK host computer

Prepare the development kit host computer

  1. Sign in as a Local Administrator to your development kit host computer.

  2. Ensure that the CloudBuilder.vhdx file has been moved to the root of the C:\ drive (C:\CloudBuilder.vhdx).

  3. Run the following script to download the development kit installer file (asdk-installer.ps1) from the Azure Stack GitHub tools repository to the C:\AzureStack_Installer folder on your development kit host computer:

  4. Be sure to download the asdk-installer.ps1 file each time you install the ASDK using the below script.

# Variables
$Uri = ‘https://raw.githubusercontent.com/Azure/AzureStack-Tools/master/Deployment/asdk-installer.ps1′
$LocalPath = ‘C:\AzureStack_Installer’
# Create folder
New-Item $LocalPath -Type directory
# Enforce usage of TLSv1.2 to download from GitHub
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
# Download file
Invoke-WebRequest $uri -OutFile ($LocalPath + ‘\’ + ‘asdk-installer.ps1’)

5. From an elevated PowerShell console, start the C:\AzureStack_Installer\asdk-installer.ps1 script, and then click Prepare Environment.

6. On the Select Cloudbuilder vhdx page of the installer, browse to and select the cloudbuilder.vhdx file that you downloaded and extracted in the previous steps. On this page, you can also, optionally, enable the Add drivers check box if you need to add additional drivers to the development kit host computer. Click Next.

7. On the Optional settings page, provide the local administrator account information for the development kit host computer and then click Next.
If you don’t provide the local administrator credentials in this step, you’ll need direct or KVM access to the host after the computer restarts as part of setting up the development kit.

You can also provide values for the following optional settings:

  • Computername: This option sets the name for the development kit host. The name must comply with FQDN requirements and must be 15 characters or less in length. The default is a random computer name generated by Windows.
  • Static IP configuration: Sets your deployment to use a static IP address. Otherwise, when the installer reboots into the cloudbuilder.vhdx, the network interfaces are configured with DHCP. If you choose to use a static IP configuration, additional options are displayed where you must also:
    • Select a network adapter. Make sure you can connect to the adapter before you click Next.
    • Make sure that the displayed IP address, Gateway, and DNS values are correct and then click Next.

8. Click Next to start the preparation process.

9. When the preparation indicates Completed, click Next.

10. Click Reboot now to boot the development kit host computer into the cloudbuilder.vhdx and continue the deployment process.

Download and extract the Azure Stack Development Kit (ASDK)

Download the ASDK

  1. Before you start the download, make sure that your computer meets the following prerequisites:
    • The computer must have at least 60 GB of free disk space available on four separate, identical logical hard drives in addition to the operating system disk.
    • .NET Framework 4.6 (or a later version) must be installed.
  2. Go to the Get Started page where you can download the Azure Stack Development Kit, provide your details, and then click Submit.
  3. Download and run the Deployment Checker for Azure Stack Development Kit prerequisite checker script. This standalone script goes through the pre-requisites checks done by the setup for Azure Stack Development Kit. It provides a way to confirm you are meeting the hardware and software requirements, before downloading the larger package for Azure Stack Development Kit.
  4. Under Download the software, click Azure Stack Development Kit.

Extract the ASDK

  1. After the download completes, click Run to launch the ASDK self-extractor (AzureStackDevelopmentKit.exe).
  2. Review and accept the displayed license agreement from the License Agreement page of the Self-Extractor Wizard and then click Next.
  3. Review the privacy statement information displayed on the Important Notice page of the Self-Extractor Wizard and then click Next.
  4. Select the location for Azure Stack setup files to be extracted to on the Select Destination Location page of the Self-Extractor Wizard and then click Next. The default location is current folder\Azure Stack Development Kit.
  5. Review the destination location summary on the Ready to Extract page of the Self-Extractor Wizard, and then click Extract to extract the CloudBuilder.vhdx (approximately 28GB) and ThirdPartyLicenses.rtf files. This process takes some time to complete.
  6. Copy or move the CloudBuilder.vhdx file to the root of the C:\ drive (C:\CloudBuilder.vhdx) on the ASDK host computer.

Azure Stack – hardware and Software requirements

Before you deploy the Azure Stack Development Kit (ASDK), make sure your development kit host computer meets the requirements described in this article.

Hardware

Component Minimum Recommended
Disk drives: Operating System 1 operating system disk with minimum of 200 GB available for system partition (SSD or HDD) 1 OS disk with minimum of 200 GB available for system partition (SSD or HDD)
Disk drives: General development kit data* 4 disks. Each disk provides a minimum of 240 GB of capacity (SSD or HDD). All available disks are used. 4 disks. Each disk provides a minimum of 400 GB of capacity (SSD or HDD). All available disks are used.
Compute: CPU Dual-Socket: 16 Physical Cores (total) Dual-Socket: 20 Physical Cores (total)
Compute: Memory 192 GB RAM 256 GB RAM
Compute: BIOS Hyper-V Enabled (with SLAT support) Hyper-V Enabled (with SLAT support)
Network: NIC Windows Server 2012 R2 Certification. No specialized features required Windows Server 2012 R2 Certification. No specialized features required
HW logo certification Certified for Windows Server 2012 R2 Certified for Windows Server 2016

* You need more than this recommended capacity if you plan on adding many of the marketplace items from Azure.

Data disk drive configuration: All data drives must be of the same type (all SAS, all SATA, or all NVMe) and capacity. If SAS disk drives are used, the disk drives must be attached via a single path (no MPIO, multi-path support is provided).

HBA configuration options

  • (Preferred) Simple HBA
  • RAID HBA – Adapter must be configured in “pass through” mode
  • RAID HBA – Disks should be configured as Single-Disk, RAID-0

Supported bus and media type combinations

  • SATA HDD
  • SAS HDD
  • RAID HDD
  • RAID SSD (If the media type is unspecified/unknown*)
  • SATA SSD + SATA HDD
  • SAS SSD + SAS HDD
  • NVMe

* RAID controllers without pass-through capability can’t recognize the media type. Such controllers mark both HDD and SSD as Unspecified. In that case, the SSD is used as persistent storage instead of caching devices. Therefore, you can deploy the development kit on those SSDs.

Example HBAs: LSI 9207-8i, LSI-9300-8i, or LSI-9265-8i in pass-through mode

Sample OEM configurations are available.

Operating system

Requirements
OS Version Windows Server 2016 or later. The operating system version isn’t critical before the deployment starts, as you’ll boot the host computer into the VHD that’s included in the Azure Stack installation. The operating system and all required patches are already integrated into the image. Don’t use any keys to activate any Windows Server instances used in the development kit.

Account requirements

Typically, you deploy the development kit with internet connectivity, where you can connect to Microsoft Azure. In this case, you must configure an Azure Active Directory (Azure AD) account to deploy the development kit.

If your environment is not connected to the internet, or you don’t want to use Azure AD, you can deploy Azure Stack by using Active Directory Federation Services (AD FS). The development kit includes its own AD FS and Active Directory Domain Services instances. If you deploy by using this option, you don’t have to set up accounts ahead of time.

Network

Switch

One available port on a switch for the development kit machine.

The development kit machine supports connecting to a switch access port or trunk port. No specialized features are required on the switch. If you are using a trunk port or if you need to configure a VLAN ID, you have to provide the VLAN ID as a deployment parameter.

Subnet

Do not connect the development kit machine to the following subnets:

  • 192.168.200.0/24
  • 192.168.100.0/27
  • 192.168.101.0/26
  • 192.168.102.0/24
  • 192.168.103.0/25
  • 192.168.104.0/25

These subnets are reserved for the internal networks within the development kit environment.

IPv4/IPv6

Only IPv4 is supported. You cannot create IPv6 networks.

DHCP

Make sure there is a DHCP server available on the network that the NIC connects to. If DHCP is not available, you must prepare an additional static IPv4 network besides the one used by host. You must provide that IP address and gateway as a deployment parameter.

Internet access

Azure Stack requires access to the Internet, either directly or through a transparent proxy. Azure Stack does not support the configuration of a web proxy to enable Internet access. Both the host IP and the new IP assigned to the AzS-BGPNAT01 (by DHCP or static IP) must be able to access Internet. Ports 80 and 443 are used under the graph.windows.net and login.microsoftonline.com domains.

Move-CsUser : Unable to locate Windows Live ID token from the provided credentials, or fr om Active Directory Federation Services (AD FS) credentials cache.

PROBLEM

I am getting below error while trying to move the on-premises lync 2013 user to Skype Online.

O365 Sign in method – Seamless Single Sign-on
ADFS Services – Stopped

ADConnect Sync – OK

Password Write back – Enabled

Move-CsUser -Identity “mailtest@domain.com” -Target sipfed.online.lync.com -Confirm:$false -Verbose

VERBOSE: CN=MailTest,OU=Test,OU=Users,OU=IT,OU……………..DC=local

WARNING: Moving a user from the current version to an earlier version (or to a service

version) can cause data loss.

VERBOSE:CN=MailTest,OU=Test,OU=Users,OU=IT,OU……………..DC=local

Move-CsUser : Unable to locate Windows Live ID token from the provided credentials, or fr

om Active Directory Federation Services (AD FS) credentials cache.

At line:1 char:1

+ Move-CsUser -Identity “mailtest@domain.com” -Target sipfed.online.lync.com -Co …

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidOperation: (CN=MailTest,OU=………..DC=local:OCSAD

User) [Move-CsUser], MoveUserException

+ FullyQualifiedErrorId : MoveError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsUserC

mdlet

Move-CsUser : HostedMigration fault: Error=(510), Description=(This user’s tenant is not enabled for shared sip address space.)

PROBLEM

In a Lync hybrid deployment, when you try to move users from the on-premises server that is running Lync to Skype for Business Online (formerly Lync Online) in Office 365, you receive the following error message in Skype for Business Online PowerShell:

Move-CsUser : HostedMigration fault: Error=(510), Description=(This user’s tenant is not enabled for shared sip address space.)

SOLUTION

Before you try to migrate an on-premises Lync user to Skype for Business Online in Office 365, your Office 365 Skype for Business Online organization must be enabled for Shared Session Initiation Protocol (SIP) Address Space.

Set-CsTenantFederationConfiguration -SharedSipAddressSpace $true

 

How to connect to Skype for Business Online PowerShell

The first step is to install the Windows PowerShell Module for Skype for Business Online. For information, go to the following Microsoft website:

After you have the Skype for Business Online Connector module installed, open Windows PowerShell, and then run the following commands:

Import-Module LyncOnlineConnector

 

$cred = Get-Credential

 

$CSSession = New-CsOnlineSession -Credential $cred

 

Import-PSSession $CSSession -AllowClobber

For more information about how to connect to Skype for Business Online by using Windows PowerShell, go to the following Microsoft TechNet website:

409 Client Error: Conflict for url: Zone file path record name while importing a zone file to Azure DNS using CLI

Issue: –

You received this error while importing zone file using the CLI method to Azure DNS.

409 Client Error: Conflict for url: Zone file path

 

Cause:- 

There is always a limit of records you can import to the Azure DNS zone. Let say MS set a limit of 2000 records and you try to import a file more than 2000 DNS records.

Resolution:-

If you are importing more records than it shows in Azure DNS portal then you will getting this error when during the import, the records count reached the limit. Simply ask Microsoft to increase the records limit for each zone file.