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.

How to to create the service connection point in the forest where computers exist to allow devices sync to Azure

Use below scrip to create a service connection point so that device sync can be enabled for Azure.

$verifiedDomain = “contoso.com”    # Replace this with any of your verified domain names in Azure AD

$tenantID = “72f988bf-86f1-41af-91ab-2d7cd011db47”    # Replace this with you tenant ID

$configNC = “CN=Configuration,DC=corp,DC=contoso,DC=com”    # Replace this with your AD configuration naming context (use Get-ADRootDSE to get this value)

$de = New-Object System.DirectoryServices.DirectoryEntry

$de.Path = “LDAP://CN=Services,” + $configNC

$deDRC = $de.Children.Add(“CN=Device Registration Configuration”, “container”)

$deDRC.CommitChanges()

$deSCP = $deDRC.Children.Add(“CN=62a0ff2e-97b9-4513-943f-0d221bd30080”, “serviceConnectionPoint”)

$deSCP.Properties[“keywords”].Add(“azureADName:” + $verifiedDomain)

$deSCP.Properties[“keywords”].Add(“azureADId:” + $tenantID)

$deSCP.CommitChanges()

Error: No-Start-Connection in AD Connect Export Sync

Getting this error while exporting the objects in AD Connect. You will also see the below result in Sync service.

image

 

Resolution:- To resolve this issue go to Connectors, go to the properties of the connector giving the above error, select “Connect to Active Directory Forest” option and provide the credentials to connect. Once this is successful then sync will start again.

How to put O365 mailbox on in-place hold using the Exchange Online powershell

In Exchange Server, In-Place Hold functionality is integrated with In-Place eDiscovery searches. You can use the In-Place eDiscovery & Hold wizard in the Exchange Administration Center (EAC) or the New-MailboxSearch and related cmdlets in Exchange Management Shell to place a mailbox on In-Place Hold.

Connect to Exchange online powershell and run the below command

New-MailboxSearch -Name “NameOfMailbox” -SourceMailboxes EmailAddress -ExcludeDuplicateMessages $True -InPlaceHoldEnabled $true -ItemHoldPeriod Number of Days -Description In-PlaceHoldDescription

 

Many organizations require that users be informed when they’re placed on hold. Additionally, when a mailbox is on hold, any retention policies applicable to the mailbox user don’t need to be suspended. Because messages continue to be deleted as expected, users may not notice they’re on hold. If your organization requires that users on hold be informed, you can add a notification message to the mailbox user’s Retention Comment property and use the RetentionUrl property to link to a web page for more information. Outlook 2010 and later displays the notification and URL in the backstage area. You must use the Shell to add and manage these properties for a mailbox.

Difference Between Azure AD Connect and Single Sign-On Options

Azure AD Connect offers customers a number of ways to enable a “Single Sign-On” (or SSO) experience for users. I think it is important to understand the differences in these options, so that when you deploy Azure AD Connect into customer environments, you can pick the right solution to suit the business needs.

Single Sign-On is an experience, wherein a single logon event (like logging into your local workstation) will automatically qualify you for login to other, disparate systems (e.g. Office 365)–in other words, you have all the tokens, exchanges and mechanisms in place that are needed just from your primary logon event. From the user’s perspective: after signing into the local Active Directory network on their workstation using a corporate email address, they might then open a web browser, point it at https://mail.office365.com, and automatically be signed into their Office 365 mailbox, without having to provide credentials a second time. This is (so to speak) a “true” SSO experience.

There are three primary methods we can use to achieve “true” SSO:

  1. Password Hash Synchronization with Seamless Single Sign-On enabled
  2. Pass-Through Authentication with Seamless Single Sign-On enabled
  3. Active Directory Federated Services

I am actually going to start with this last option, which was in fact, the original. Many early adopters of the 365 platform ended up with this type of configuration.

Pass-Through Authentication with Seamless SSO

Pass Through Authentication or PTA is the simplified cousin of AD FS. It works both very similarly, AND very differently from the above solution.

Similar to AD FS, it means that all logins rely on the local Active Directory for authentication and sign-in–we still have that same annoying dependency. However, because the cloud authentication takes place via the local Azure AD Connect service, and does not require a complex AD FS server infrastructure or SSL certificates, it might be preferred in some scenarios. You would still want the redundant ISP links, but there are no additional requirements. Therefore, if you are faced with the challenge of keeping passwords and authentication events on-premises, and the customer also wants to keep the complexity down with a lighter on-premises footprint, then PTA is your best option (be sure to also enable SSO in the AAD Connect configuration wizard when choosing this option).

Pass-Through Authentication with Seamless SSO

Pass Through Authentication or PTA is the simplified cousin of AD FS. It works both very similarly, AND very differently from the above solution.

Similar to AD FS, it means that all logins rely on the local Active Directory for authentication and sign-in–we still have that same annoying dependency. However, because the cloud authentication takes place via the local Azure AD Connect service, and does not require a complex AD FS server infrastructure or SSL certificates, it might be preferred in some scenarios. You would still want the redundant ISP links, but there are no additional requirements. Therefore, if you are faced with the challenge of keeping passwords and authentication events on-premises, and the customer also wants to keep the complexity down with a lighter on-premises footprint, then PTA is your best option (be sure to also enable SSO in the AAD Connect configuration wizard when choosing this option).

Active Directory Federated Services (AD FS)

With AD FS, you need to deploy an on-premises service called Active Directory Federated Services, and it’s best if you make this service highly available. In this configuration, passwords never leave the on-premises Active Directory.  When someone attempts to sign-in to the Azure AD application, there is a configuration bit in the tenant that says “I’m not in charge of authentication, I have to go check in with <insert corporate AD FS web address here>.” This is super cool for security and compliance, because all authentication attempts are still logged against the local Active Directory.

But it is super uncool for many small businesses, because it requires setup and installation of AD FS, which also means that the cloud-based applications are dependent on the local Active Directory. So, if the corporate internet connection is down, so is your email. Wait a minute… why did we move our email to the cloud again? To prevent this scenario, our design would need to include:

  1. Properly configured AD FS infrastructure with SSL Certificates
  2. At least 2x AD FS web servers on separate links/ISP’s for HA
  3. Planned recovery from total loss of this site/infrastructure

Not a popular option for these reasons (complexity + dependency).

There are a couple of other considerations that might come into play. Most notably, the only solution here that supports the on-premises Multifactor Authentication Server is (unfortunately) AD FS. It is still possible to enable MFA for cloud-based applications using Azure AD MFA provider with the other options, but you do not have the ability to bring MFA to your network locally, without AD FS. Just something to be aware of.  On the flip side, it is worth noting that Azure Identity Protection (which requires additional licensing, e.g. P2) is not compatible with AD FS (because the authentication attempts must happen against Azure AD for Azure ID Protection reports to work).

Another consideration that applies only to PHS w/ SSO enabled: there may be a delay between, for example, disabling an account on-premises, and having that change updated in the cloud (because AAD Connect only synchronizes every 30 minutes by default). Furthermore, users who have passwords synchronized to Azure AD will technically have their cloud passwords set to never expire, and the password policies that apply on-premises will control when they need to update their password–but it is enforced on-premises only. Therefore it is possible, for example, to sign-in to cloud-based resources, even if the password on-premises has expired, because until the user changes the on-premises password, the old value will not be overwritten in the cloud.

There may be other small differences, but these are the noticeable ones that matter most to small businesses. I have summarized all of these points into this table for ease of reference: