Category Archives: Azure

Azure AD Premium Conditional Access for Domain Joined Machines

This article is an attempt at discovering what the minimum steps are to get the Conditional Access feature which checks for Domain Join status for both Windows 10 and Windows 7 operating systems.

Conditional Access is a feature of the “Azure AD Premium P1 License” which can be purchased ala carte for $6/user/month, or as part of the “Enterprise Mobility + Security license” for $8.75/user/month, or the new Microsoft 365 SKU announced at the 2017 Inspire conference.

This is what the feature looks like when configuring a Conditional Access Policy in the Azure Portal to only permit domain joined devices:

For more information about Conditional Access, read about it here.

I had the following questions:

  • What does the conditional policy mean by “Domain Join” – is it on-premises or is it Azure AD Domain Join, both, or something else? (Answer: on-prem domain join with an account that has been synced by Azure AD Connect to the cloud… with a software deployment required for Windows 7, and a GPO required for Windows 10).
  • Is it necessary to deploy the Workplace Join v2.1 client to Windows 7 Machines? (Answer: Yes)
  • Does Azure AD Connect require configuration, and if so, what is the minimum version of Azure AD Connect required? (Yes, you must create a service connection point in Active Directory per this article).
  • What role does Azure AD Seamless Single Sign-On Play (also referred to as “Desktop SSO” in the Azure AD Connect documentation) Answer: (It provides a similar SSO experience to ADFS, but only when connected to the corporate network. And it is REQUIRED for Windows 7 machines that wish to have Workplace Join work without an ADFS server).
  • Is ADFS required? (Answer: No)
  • Is there any configuration necessary in Azure AD? (Answer: Not unless you changed the default settings)
  • Is it necessary to deploy a Group Policy change? If so, what are those changes? (Answer: For Windows 10, Yes, see below. For Windows 7, you’ll need to push out some Intranet Site to Zone mappings for the Azure Seamless SSO to work)
  • Is it necessary to create any DNS records? (Answer: Yes, see below)

Domain Join vs Azure AD Domain Join vs Azure AD Registration

If you configure a Conditional Access Policy and select the “require domain joined device” checkbox, what is it checking?

To find out, I created 6 virtual machines to see exactly what works and what does not work.

Computer Name Operating System Configuration Test Results Notes
Win10DomainJoin Windows 10.0.15063 (Creators)
  1. On-Prem Domain Joined
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
Success
Win10DJandReg Windows 10.0.15063 (Creators)
  1. On-Prem Domain Joined
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
  4. GPO Applied “Register domain-joined computers as devices”
Success  
Win10DJandAADJ Windows 10.0.15063 (Creators)
  1. On-Prem Domain Joined
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
  4. Azure AD Domain Joined (aka ‘Workplace Joined’)
  5. GPO *NOT* Applied “Register domain-joined computers as devices”
Success
Win10AADJoined Windows 10.0.15063 (Creators)
  1. Azure AD Joined Only
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
  4. GPO *NOT* Applied “Register domain-joined computers as devices”
Fail – Got a block page (see block page example below) Wasn’t entirely expecting this to work since the screen tip that is in-band of the configuration says that this checkbox does *not* apply to Azure AD joined machines.

Win7DomainJoin Windows 7 SP1
  1. Azure AD Joined Only
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
Fail – Got a block page (see block page example below) Wasn’t expecting this to work – just testing to create a baseline before the Workplace Join client was installed. With no ADFS in the environment – just Azure AD Connect with Desktop SSO and Password Hash Sync.
Win7DJwithWPJ Windows 7 SP1
  1. Azure AD Joined Only
  2. Azure AD Connect “Desktop SSO” is enabled
  3. “enterpriseregistration” DNS CNAME exists
  4. Workplace Join v2.1 client installed
SUCCESS I was starting to lose hope after all these failed tests, but we now have a successful test!

The common denominator for the successful test was the DeviceTrustLevel changed to “Managed”

Block Page Example

This is the end-user example of what it looks like when you try to open an application protected by a Conditional Access Policy that requires Domain Join.

DNS Records

According to the documentation, is necessary to register the following DNS CNAME record in both internal and external DNS (if using split-zone / split-brain DNS):

DNS Entry Type DNS Value (Address)
enterpriseregistration.contoso.com CNAME enterpriseregistration.windows.net

Workplace Join v2.1

For Windows 7 and Windows 8.1 devices, the documentation states that it is necessary to deploy the Workplace Join client (MSI Package) from here. This is not required for Windows 10 systems, which can register to Azure AD via group policy, although in my lab that does not appear to be working, as that does not produce any records when I run get-msoldevice. Perhaps it requires ADFS for Windows 10 machines to work with Domain Join conditional access.

Workplace join Version 2.1 (Released June 2017) added support for Azure Active Directory Seamless Single Sign On (https://aka.ms/hybrid/sso).

Ready for some kludge? The installer creates a scheduled task on the system that runs in the user’s context. The task is triggered when the user signs in to Windows. The task silently registers the device with Azure AD with the user credentials after authenticating using Integrated Windows Authentication. To see the scheduled task, in the device, go to Microsoft > Workplace Join, and then go to the Task Scheduler library.

The two main benefits of this tool in my opinion is that it registers a Windows 7 machine in Azure AD, and, the version 2.1 client makes it so that you don’t have to use ADFS (simplifying the configuration).

Azure AD Seamless Single Sign-On

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) is required for Windows 7 machines if you are not using ADFS. Instead, users will sign in and register to Azure Device Registration Services.

When enabled, users don’t need to type in their passwords to sign in to Azure AD, and usually, even type in their usernames. This feature provides your users easy access to your cloud-based applications without needing any additional on-premises components.

If you have ADFS, you do not need this feature as ADFS already provides “seamless SSO” (assuming you also deployed the ADFS STS web page to your Local Intranet zone in Internet Explorer).

*Note: The ‘Edge’ web browser is not yet supported. Currently IE, Chrome and Firefox are supported. Firefox requires custom configuration to make it work.

To deploy seamless SSO, you turn it on in Azure AD Connect, then you deploy it through Group Policy.

Azure AD Connect

You must be using version 1.1.484.0 or later of Azure AD Connect. Note: In the screen shot below, Pass-through auth is selected but ‘Password Synchronization’ could have been chosen as well.

If you already have an installation of Azure AD Connect, choose “Change user sign-in page” on Azure AD Connect and click “Next”. Then check the “Enable single sign on” option

Completing that step will create a new computer object in Active Directory “AZUREADSSOACC” – if this object is accidentally deleted, users can still logon, but it will just be the standard logon just like prior to seamless SSO being enabled (so it ‘fails open’ so to speak). For more information see the technical deep dive here.

Group Policy

You can add the Azure AD device authentication end-point to the local Intranet zones to avoid certificate prompts when authenticating the device. This works for both IE and Chrome which both share the same setting. For other browsers see the references section.

To roll this out in a group policy object, here are the steps:

  1. Open the Group Policy Management tool on a domain controller, ex: start > run > gpmc.msc
  2. Edit the Group Policy that is applied to some or all your users.
  3. Navigate to User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page and select Site to Zone Assignment List

    Enable the policy, and enter the following values (1 indicates Intranet zone) in the dialog box.

    https://device.login.microsoftonline.com

    https://autologon.microsoftazuread-sso.com

    https://aadg.windows.net.nsatc.net

    Note: One of the references only listed the first URL, whereas another reference listed the bottom two. Since the documentation was not consistent, I’m including all three to be safe.

    Note: Rollout the above GPO at your own risk… It will add these and lock out/remove any other intranet site zones your users may have manually configured. My personal preference is to deploy these as group policy preferences instead.

    ADFS

    ADFS is not required as long as you deploy the Workplace Join v2.1 client to your Windows 7 systems, and you deploy Azure AD Seamless SSO.
    Reference: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq#i-want-to-register-non-windows-10-devices-with-azure-ad-without-using-ad-fs-can-i-use-seamless-sso-instead

    Azure AD Configuration

    By default, Azure AD enables users to register devices. So unless someone in your organization changed this setting, you should not have to change this. This is found in http://portal.azure.com then find Azure Active Directory > Users and groups > Device settings. The policy “Users may register their devices with Azure AD” must be set to “All” (which is the default setting).

    Windows 10

    All domain-joined devices running Windows 10 Anniversary Update and Windows Server 2016 automatically register with Azure AD at device restart or user sign-in. However, Windows 10 November 2015 Update automatically registers with Azure AD only if the rollout Group Policy object is set. So the best thing to do is configure a Group Policy object to control the rollout of automatic registration of Windows 10 and Windows Server 2016 domain-joined computers.

    Go to Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration. Right-click Register domain-joined computers as devices, and then select Edit. Select Enabled, and then select Apply.

  • Older GPMC Consoles may see: Computer Configuration > Policies > Administrative Templates > Windows Components > Workplace Join > Automatically workplace join client computers. Select Enabled, and then select Apply.


Testing

You can check successful registered devices in your organization by using the Get-MsolDevice cmdlet in the Azure Active Directory PowerShell module.+

The output of this cmdlet shows devices registered in Azure AD. To get all devices, use the -All parameter, and then filter them using the deviceTrustType property. Domain joined devices have a value of Domain Joined. In my testing, the only combination that seemed to work with conditional access is when the DeviceTrustType was Domain Joined, and the DeviceTrustLevel was Managed.


To test the scenario where the user enters only the username, but not the password:

Troubleshooting

  1. Check to make sure the computer account is syncing to the cloud by running get-msoldevice. If it does not show up there, then make sure the OU or container containing the computer objects is being synced. If it shows up there, it must have DeviceTrustType = ‘Domain Joined’ and DeviceTrustLevel = ‘Managed’
  2. For Windows 10 only, Check to see if the computer object contains a value in the userCertificate attribute. If not, this means that the computer is unable to read the value of the SCP object in Active Directory. Check to make sure that the Authenticated Users group is not missing from the “Device Registration Configuration” object.  To see if it can query the SCP, run this command:
    $config = [ADSI] “LDAP://CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=YourDomain,DC=com”;$config
  3. On Windows 10, Run the dsregcmd /status and make sure ‘AzureAdJoined’ is Yes and ‘IsUserAzureAD’ is Yes
    Under User State, verify that WamDefaultSet is Yes, WamDefaultAuthority is organizations, WamDefaultId is https://login.microsoft.com, AzureAdPrt is Yes, and WamDefaultGUID contains a value.
  4. For Windows 7 only, run autoWorkplaceJoin.exe /i to find out the current status of the device, this will also provide helpful error messages as well.
  5. Enable Debug and Analytic logs in Event Viewer. Click the View menu. Select Show Analytic and Debug Logs to make these logs visible. Enable logs under Applications and Services Logs > Microsoft > Windows > User Device Registration, and then export the logs for Admin and Analytic folders about five minutes after you have rebooted (or signed-out/in)
  6. Check the troubleshooting article https://docs.microsoft.com/en-us/azure/active-directory/device-management-troubleshoot-hybrid-join-windows-current
  7. When pushing out the Workplace Join Client, users may get a pop-up “To continue, this application needs to create a key.”

    To suppress this, you can push out a group policy object to not require user input for storing certificates.

 

Top 5 Azure Information Protection Limitations

Before I discuss the limitations of any product, I try my best to point out all of the things I appreciate about a product. In general, you will not hear Microsoft tell you about product limitations. I suspect it is a culture thing. But then again, do you expect a new car salesman to tell you about the limitations of the car they are trying to sell you?

So let me first point out that I have been a longtime fan of Microsoft’s Rights Management Services (RMS) which debuted in Windows Server 2003. As the product evolved over the years into what is now called Azure Information Protection, I became an even greater admirer of the product as well as the team within Microsoft responsible for its development.

A key milestone came when RMS was ported to Azure, because it became easy to enable (with one mouse click), eliminating the effort to configure servers on-premises, and especially the underlying Public Key Infrastructure (PKI) environment that RMS required.

With the rise in popularity of Office 365 (100 Million subscribers), many began to take advantage of RMS because it is included for free in the most popular business subscription (known as the “E3” license).

One of my favorite RMS features came in September of 2015, when Microsoft announced Document Tracking and Revocation capabilities (here). I’m still amazed by how cool this feature is, allowing you to see a map of the world and the location of where your documents have been opened!

Another key milestone in the evolution of RMS came when they acquired Secure Islands (announced by Takeshi Numoto on 11/9/2015). Six months later, Dan Plastina (@TheRMSGuy) first announced on 6/22/16 (here) that RMS would be rebranded as “Azure Information Protection” (AIP) and later reached general availability in October 2016 (here).

AIP is a truly jaw-dropping experience. As you are authoring content, the document will automatically be labeled and encrypted with a strong 2048 bit encryption key on-the-fly if sensitive information is found (ex: credit card numbers, social security numbers, or data you define as sensitive using regular expressions).

As a consultant, my job is to listen to customer problems, and then recommend solutions. This leads me to the title of this post – AIP Limitations.

Azure Information Protection Limitations

1. External Sharing using AIP with business partners who are still running Office 2010 (or older) needs improvement

When you protect a document with AIP, and you want to send that document to an external user, things go smoothly if they are running Office 2013 or Office 2016.

However, a lot of companies still run Office 2010. This is what their experience would look like:

“Dear External User,

We would like to share sensitive documents with you. If you are running Office 2013 or 2016, and if you have an Office 365 subscription, then you should be able to open the attachments without a problem.

Otherwise, if you are using Office 2010, you will need the following before you can open the documents we send you:

      1. Local Administrator Rights are required to install the Azure Information Protection Client
      2. Download and install the Azure Information Protection Client
        1. If you are running Windows 7, you first need to install KB 2533623 (This will require a reboot)
        2. Note: Office 2010 require Microsoft Online Services Sign-in Assistant version 7.250.4303.0. This version is included with the AIP client installation, however, if you have a later version of the Sign-in Assistant, uninstall it before you install the Azure Information Protection client.
        3. Note: The AIP Client will automatically install the .NET 4.6.2 Framework, so be sure not to deploy this on any machine that has known compatibility issues with the 4.6.2 framework.
      3. Be advised, that in some cases, even if you follow all of the steps above, you may still get an error message when attempting to open an RMS or AIP protected document in Office 2010. The work-around is to create a few registry entries for the service location as documented in the AIP Client Admin guide (here).

If you do not have an Office 365 Subscription, you will need to sign up for “RMS for Individuals” (this is a free identity platform that allows you to open the documents we send to you).”

2. Ad/Hoc External Sharing using an AIP Label is not possible

Let’s say you get a call from a new customer or business partner who wants you to send them a Microsoft Word document. The document is too large to email so you host it in online storage (ex: OneDrive, SharePoint, Dropbox, etc). You might be tempted to click an AIP label that says “Business Partner” or “Client Confidential” but that would not work in the current implementation of AIP, because the Labels must be associated with an RMS Template, and RMS Templates must be associated with Mail Enabled Security Groups, and those Groups must contain a Contact Object. Since normal end-users cannot create contact objects in their Active Directory or Azure Active Directory, they must submit a helpdesk ticket for the external contact to be created, then added to the appropriate Mail Enabled Security Group. You get the picture that this process just broke down fast. Essentially, there is no way with AIP today to associate a label with ad/hoc external sharing. Labels can only be used for defined and known business partners who are pre-configured as contact objects in a group associated with an RMS template that is then tied to a Label. It would be just as exhausting to implement this in a process as it was to type this all out I am sure!

3. There is no Mac OSX client for Azure Information Protection.
The work-around, as best as I can tell, is to have Mac users try the legacy “RMS Sharing App” for Mac OSX. This was the application written before the AIP client was released.

4.In April of 2016, there was a vulnerability discovered in the RMS technology that allows someone with View rights to escalate their privilege and change the document by stripping RMS from the document (which could be potentially undesirable if they then re-share that document with unauthorized parties, or if that document is exposed in the wild (ex: lost/stolen laptop, ransomware, etc). This is documented on Wikipedia here, and proof of concept code is available for testing from GitHub (here). This issue isn’t too great in my opinion, because it requires that one of the named users who is authorized to view the document has to compromise the document. In other words, an unauthorized party cannot break the 2048 bit encryption.

5.OneDrive.
Protecting documents with AIP or RMS automatically when they are uploaded to OneDrive is currently not a great idea. First, Microsoft has removed the navigation button permitting you to do this, so you would have to find the direct hyperlink to the document library settings to enable IRM on your OneDrive document library. Even if you were to do this, it would prevent you from sharing any of those documents with outside users because there is no straight-forward way to make a OneDrive library’s IRM settings understand external users. It essentially ends the ad/hoc sharing capabilities of OneDrive. Perhaps that is why MSFT removed the navigation button for site settings in OneDrive.

Guidance

So given these limitations, what do I recommend?

  • I recommend you use AIP to protect sensitive information that should be accessible to internal employees, or known/named individuals from business partners. When communicating with the business partner for the first time, try to find out if they use Office 2010, and if so, warn them that it will be a rocky road for them (see sample email template above). Fortunately, Office 2013 and 2016 seem to natively open AIP encrypted documents.
  • If you need to share documents with encryption in transit, then use Office 365 Message Encryption (OME). The limitation of OME (today) is that the recipient can save the document and do anything they want to it (the encryption does not follow the attachments after the recipient saves it to their computer). This will be resolved with the upcoming Secure Email feature that was announced at the 2016 Ignite conference.
  • If you need to securely share emails and documents with Gmail users, then wait for the upcoming Secure Email solution that was announced at the 2016 Microsoft ignite conference (watch the video here, starting around the 46 minute mark).

Roadmap

Will things get better? In many cases, yes, however, not for the external user who needs to edit the AIP/RMS protected document using Office 2010.
The proposed Secure Email solution will make it seemless for any user to VIEW AIP/RMS protected documents by providing a web-browser experience. But if the business process requires the external user to make changes and send those back, my understanding is that capability is not going to be in Secure Email when it is released (from what I have heard anyway). To be clear, if the external user is given edit rights, and if they are still on Office 2010, they are going to have the same pain points as I described above with Office 2010.

AIP Licensing

AIP can be licensed in one of four methods:

  1. You can get AIP as a standalone license for $2/user/month.
  2. You can get AIP as part of the Azure Active Directory Premium P1 or P2 license families.
  3. You can get AIP in the Enterprise Mobility + Security E3 or E5 license families.
  4. Or you can get AIP as part of the Secure Productive Enterprise E3 or E5 license families.

If you just need the original RMS capabilities (encryption, access control and policy enforcement) then you can license that individually or as part of the Office 365 E3 license.

If you need the Document Tracking and Revocation Capabilities, you’ll find that in the Enterprise Mobility + Security E3 or Secure Productive Enterprise E3.

Note: AIP automatic labeling is an advanced feature that requires the AADP P2, or EMS E5, or SPE E5 license. Otherwise, the down-level version of AIP requires the user to manually label documents they create.

Moving from Azure Classic to Azure Resource Manager (ARM)

Microsoft has made great strides it making it easy to migrate from Azure Classic (aka IaaS 1.0) to Azure Resource Manager, (aka ARM or what I consider IaaS v2.0).

At a very high level, the process involves migrating the vNet first, which automatically migrates the underlying VM’s. Then the next step is to migrate the storage accounts.

This process is straight-forward and easy to follow the step-by-step guidance in PowerShell (here) and there is a nice video walkthrough (here).

One interesting thing I observed is that the vNet, VM and Storage account will all have the “-Migrated” name appended to the end of the previously named object.

At this time it doesn’t appear possible to rename a resource group (feature request is marked as ‘pending’ on this website here).

The work-around is to create a new resource group and then migrate the migrated objects into the new group.

Avoid Cisco Meraki for S2S VPN with Azure

Just got off a phone call with some engineers at Microsoft who informed me that both Cisco and Microsoft have mutually agreed that using a Cisco Meraki firewall is not recommended for creating site to site (S2S) VPN tunnels to Microsoft Azure.

The issue is the Phase 1 IKE Timeout value that the Meraki uses is not supported.

This was rumored to be fixed in late 2016, and then later in a firmware update in February 2017, but as of yet, we have not seen it yet.

If anyone has updated information on this please post it in the comments as I have a few clients running the Meraki’s.

Thanks,

Joe

Top five reasons to consider Azure DNS

Azure DNS was first announced at the Microsoft Ignite conference in Chicago in May of 2015. I was there in the conference session when it was announced, because I confess – I love DNS. In this blog post I will provide some criteria that can help you determine whether Azure DNS is right for your external DNS zones. Warning: This is a 300 level article – if you do not have an intermediate understanding of DNS, I recommend first reading this article (here).

Since Azure DNS was announced almost 12 months ago, the only administration interface for Azure DNS was PowerShell. This limited the early adoption of Azure DNS to hyper enthusiasts (like myself) or people who look for any excuse to use PowerShell (you know who you are!). Microsoft announced today that Azure DNS can now be managed in the new Azure Portal, which is now sure to increase interest and adoption of this service.  So if you are managing your DNS today, why switch to Azure DNS?  Here are a few principles that I suggest for guiding this decision:

  1. Are your external DNS zones hosted on an unsupported version of Windows Server? If so, then this would be an opportunity to migrate to a supported solution. I have witnessed many environments where external DNS is running on Windows 2003 and even Windows 2000. The scary thing is these are internet-facing services, and since these operating systems are no longer receiving security updates, this could be an open door for hackers or worms to infiltrate into the environment.
  2. Are all of your external DNS servers in the same physical location? If so, then Azure DNS provides an opportunity to migrate to a more resilient solution since Azure DNS is automatically load balanced across multiple regions.
  3. Have you heard of a routing technique called Anycast? Unless you have deployed your own external DNS infrastructure across the world, it will be hard to beat the performance that Azure DNS offers because of its implementation of “Anycast.” DNS queries automatically route to the closest name servers for the best possible performance. And this translates into better application performance since application latency won’t be waiting on DNS responses. For a nice PDF of how Anycast works (click here).
  4. Does the idea or need to programmatically create DNS records in PowerShell downright excite you? Then Azure DNS is for you. Get your geek on with this nice walkthrough by Alexandre Brisebois. Just. Because. You. Can. https://alexandrebrisebois.wordpress.com/2015/06/11/moving-to-azure-dns/
  5. Do you need very short TTL values? Some DNS providers like Network Solutions will not allow you to create a record with anything less than a 60 minute TTL. They do this because they do not charge you by query, so they would prefer to have less DNS traffic hitting their network. Microsoft, on the other hand, charges by individual query, so it benefits them to offer low TTL values, since every time the record expires from DNS cache, that results in another query and therefore more $$ to MSFT. Smart.

image

Pricing

Azure DNS is currently in preview and prices below reflect a 50% preview discount

image

https://azure.microsoft.com/en-us/pricing/details/dns/

Tips

  • Use DNSStuff.com to create a baseline of your current DNS performance before considering switching to Azure DNS. Then run the same report after you switch to see if performance improved favorably.
  • Configure TTL values of 3600 (60 minutes)  to keep the DNS queries low and therefore your price low. Lower TTL values will give you greater flexibility to quickly redirect traffic to another host, with the tradeoff of increased cost.

Limits

Contact Support if you need the limits below increased. These are the limits during preview, so they may change when Azure DNS reaches general availability.

image

https://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/#dns-limits

Definitions

– A record set is two records with the same name. For example, two A records with the name ‘WWW’ pointing to two separate IP addresses is a single record set. You can have up to 20 ‘WWW’ records in a single record set.

– A record is a type of DNS entry such as ‘A’ ‘MX’ ‘CNAME’ ‘TXT’ ‘SRV’ and so on. You can have up to 1000 records per Azure DNS zone.

 

Getting started with Azure DNS

Disclaimer: DO not proceed on a production DNS zone –> this service is in Beta and the information below is for educational purposes only for LAB/Testing environments. Use at your own risk.

1. Create your new Zone in Azure DNS first.

image

SNAGHTML3e22816

2. Create DNS Records in your new zone

image

You can use the new GUI method when you have just a single record to update, but when you want to do bulk administration, . First, you have to have the right PowerShell modules installed and then logon to your Azure Tenant: https://azure.microsoft.com/en-us/documentation/articles/dns-getstarted-create-dnszone/

Then once you have powershell connected, a minimum of three lines of code are required to create a single record in your DNS zone. For example, to create an A record for WWW to point to 1.1.1.1, you would run these three commands:

$rs = New-AzureRmDnsRecordSet -Name “www” -RecordType “A” -ZoneName “contoso.com” -ResourceGroupName “Website” -Ttl 3600

Add-AzureRmDnsRecordConfig -RecordSet $rs -Ipv4Address 1.1.1.1

Set-AzureRmDnsRecordSet -RecordSet $rs
For more information on the PowerShell syntax, see: https://azure.microsoft.com/en-us/documentation/articles/dns-getstarted-create-recordset/

TIP:  If you were previously hosting your DNS zone on Godaddy, you can export your zone to a file for easy importing into Azure.

SNAGHTML3d328bb

5. When you are happy with your Zone then you are ready to point the world at it. This is done through Delegation. Read: “Delegate your domain to Azure” here for more info:
https://azure.microsoft.com/en-us/documentation/articles/dns-domain-delegation/

For example, in Godaddy, this is done in the Manage DNS and Settings tab > Manage.

image

These name servers can be found in your new Azure DNS settings here:

SNAGHTML3e520b5

Summary

Azure DNS is still in preview, so Microsoft’s official recommendation is to wait until it reaches the generally available milestone before migrating production zones onto it. However, if you think you would benefit from it, you can begin experimenting with it now to gain familiarity with it.

Often, hosting external DNS with your DNS registrar is free, but it may not always have the best performance. For example, when I queried the authoritative name servers for my DNS records, I received a 100ms TCP response. After switching to Azure DNS, queries against my DNS zone improved to 50ms! Therefore, Azure DNS might be worth the price when you consider the reduced latency in DNS lookups for your domain name, or the increase high availability compared to hosting it yourself.

ExpressRoute Providers in Southern California

If you work in Southern California, you may be interested in finding out which telecommunications providers have connectivity into Microsoft Data Centers such as Azure and Office 365.

The list below ranks providers based on their proximity to Southern California. For the full list of locations and providers, scroll down.

image

Note: This is not an endorsement for any particular provider, but just a list of those who have local connections near Los Angeles.

Need help with your next Office 365 Project? We can help you deploy any or all of the 21 features Included in Office 365 for a flat rate per month.  Contact us at Hello@PatriotConsultingTech.com.

The full list of providers is located here: https://azure.microsoft.com/en-us/documentation/articles/expressroute-locations/

Using the new Microsoft OMS to monitor Active Directory Health from Azure

Microsoft Operations Management Suite, which runs in Azure, can check the health of on-premises Active Directory, including replication health.

Why is it so important to check AD replication health? Well, if you are responsible for managing Active Directory then you know how easy it is for AD to become unhealthy, and you also know how problematic it can be to restore health. For example, a power outage that results in an Active Directory server going offline for longer than tombstone life of 180 days can cause ‘lingering objects’ to have to be removed.

So the best practice is to use monitoring tools to make sure AD remains healthy, so that you don’t have to spend long hours repairing AD.

image

 

Need help installing Microsoft OMS? We are here to help. Drop us a line at Hello@PatriotConsultingTech.com

Azure AD Connect (Dirsync) Password Sync taking too long

I was assisting a customer who reported that Azure AD Connect (aka Dirsync) was taking too long for passwords to synchronize. It was such a huge lag that they assumed it was broken entirely.

Upon inspecting the Application Event Log on the Dirsync server for event ID 656, I observed a large gap between when the password was set on the Domain Controller and when the Event log on the Dirsync server picked up the change.

SNAGHTML61bdfde

This is not expected because the synchronization service polls on-premises AD for password changes every 2 minutes for password updates. The overhead to then hash the password, transfer it to Azure AD’s connector, and received on the far end is an additional minute (if all the stars are aligned). So three minutes is a reasonable expectation for passwords to sync to Azure AD. However, 14 minutes? Something ain’t right!

Upon inspection in the MIIS client, I observed that the domain controller that Dirsync was connecting to was 62 milliseconds away, and *not* the nearby DC in the same site as Dirsync. This is viewable in the ‘last used’ field in the screen shot below.

The Fix

Configuring Azure AD Connect to use preferred domain controllers solved the problem.

SNAGHTML6259900

Results

This reduced the synchronization lag from 14 minutes to 40 seconds! That is a 95% percent reduction in lag!

SNAGHTML623b3f5

Need help with an Office 365 Project? Visit our website at www.PatriotConsultingTech.com or drop us a line at hello@patriotconsultingtech.com

When to use an Instance Level IP (ILPIP) in Azure

Instance Level IP addresses (ILPIP) are distinct from other types of IP addresses in Azure and have a very specific purpose and benefit. They are limited to 5 per Azure Subscription and intended to permit applications such as passive FTP to function, which requires a lot of open ports. They bypass the load balancer and firewall, allowing direct access to the VM. They do not take the place of the VIP assigned to the load balancer, but they can only be added alongside a VIP. At this time, an ILPIP cannot be added to VM’s that have multiple NICs (yet?).

image

Instance Level IP’s cannot be reserved and therefore are lost when the VM is shut down. They can dynamically register to a hostname that can be used in a CNAME record, so that if the IP changes, you are still fine as long as you point things to the CNAME record and not the IP address.  Another benefit is that the source IP address comes from the VM rather than from the IP of the load balancer.

Something to be aware of is that ILPIP’s do not use the Endpoints feature in Azure, and therefore all internet ports are open – requiring the use of a host-based firewall to be running on the VM to filter traffic.

You can assign ILPIP to an existing or new VM by piping set-AzurePublicIP as follows:

Get-AzureVM -ServiceName ftp01 -Name ftp01 | Set-AzurePublicIP -PublicIPName ftp01pip01 -IdleTimeoutInMinutes 4 -DomainNameLabel ftp01pip01 | Update-AzureVM

Then the CNAME record would point to the PublicIPFQDNs that is revealed when you run a get-AzureVM command. For example: ftppip01.ftp01.cloudapp.net

To request an ILPIP during VM creation you would use this command:

New-AzureService -ServiceName FTPService -Location "Central US"
$image = Get-AzureVMImage|?{$_.ImageName -like "*RightImage-Windows-2012R2-x64*"}
New-AzureVMConfig -Name FTPInstance -InstanceSize Small -ImageName $image.ImageName `
| Add-AzureProvisioningConfig -Windows -AdminUsername adminuser -Password MyP@ssw0rd!! `
| Set-AzurePublicIP -PublicIPName ftpip | New-AzureVM -ServiceName FTPService -Location "Central US"

References:

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-instance-level-public-ip/

http://blog.siliconvalve.com/2015/06/29/setting-instance-level-public-ips-on-azure-vms/

Containers in Windows Server 2016

Mark Russinovich demonstrates containers in Windows Server 2016. There are enhancements to the windows 2016 server kernel that allows multiple instances of user mode processes.

https://azure.microsoft.com/en-us/blog/an-early-look-containers-windows-server-2016-hyper-v-and-azure-with-mark-russinovich/

After watching the 15 minute video, here is the quiz:  what is the difference between a Windows Server 2016 Container and a Windows Server 2016 HyperV Container?

Answer: Hyper-V Containers provide isolation whereas Server 2016 Containers do not isolate the container processes form the host.

Which is right for you? A HyperV container or a Windows Server container?  Mark answers that question at 9:45.

When does a Windows Server container make sense over a HyperV container? It seems that when you do not require isolation, you would use Windows Server Containers.

Both of the above options are relevant for on-premises data centers. A 3rd option to evaluate is Azure Container Services, which is what cloud first companies will select first.