Managing your on-premises device with Azure Update Manager

Managing your on-premises device with Azure Update Manager

Azure Update Manager allows customers manage their Azure VM and on-premises devices using an agent called (MMA) Microsoft Monitoring Agent. The client will by default check if its compliant every 12 hours and the agent initiates a scan to check for update compliance within 15 minutes of the agent being restarted, before an installation and after update installation.

Azure Update Manager only supports the following OS for patch cycles

Supported Client Types

Operating SystemNotes
Windows Server 2008, Windows Server 2008 R2 RTMSupports only update assessments.
Windows 2008 R2 SP1 and later (including Windows Server 2012 and 2016).Net Framework 4.5.1 or later is required
Windows Powershell 4.0 or later is required
Windows PowerShell 5.1 is recommended for increased reliability.
CentOS 6 (x86/x64) and 7 (x64)Linux agents must have access to an update repository. Classification-based patching requires ‘yum’ to return security data which CentOS doesn’t have out of the box. For more information on classification-based patching on CentOS
Red Hat Enterprise 6 (x86/x64) and 7 (x64) Linux agents must have access to an update repository.
SUSE Linux Enterprise Server 11 (x86/x64) and 12 (x64) Linux agents must have access to an update repository.
Ubuntu 14.04 LTS, 16.04 LTS, and 18.04 (x86/x64) Linux agents must have access to an update repository.

Unsupported Client Type

Operating SystemNotes
Windows ClientClient operating systems (such was Windows 7 and Windows 10 arent supported.
Windows Server 2016 Nano ServerqNot Supported

However, the Windows Client arent supported for patch management. The MMA agent can be installed if you just require update reporting using Azure Monitor.

Where do I start in configuring Azure Update Management?

The first thing we need is an Azure Automation Account

You will need to provide details as specified below

Please Note:

Log Analytics Workspace is required later in this process and its only currently available in the following locations;

Australia Southeast
Canada Central
Central India
East US
Japan East
Southeast Asia
UK South
West Central US
West Europe
West US 2

If you want to check where functionality located, please visit this url https://azure.microsoft.com/en-us/global-infrastructure/services/?products=monitor&regions=us-east,us-east-2,us-central,us-north-central,us-south-central,us-west-central,us-west,us-west-2,canada-east,canada-central,united-kingdom-south,united-kingdom-west,non-regional,south-africa-north,south-africa-west

Once the account has been created, select the newly account and go to Update Management Section and Update Management. This will show the Location you specified, Log Analytics Workspace subscription and you can now create the Log Analytics Workspace.

Configure Automation Account for Update Management

Once you press Enable, you’ll receive a message that “The installation of the Update Management solution is in progress.”

Enable Update Management with Log Analytics Workspace

Now we have successful created the Log Analytics Workspace you will be able to build the “Schedule Update Deployment” as shown below

Update Management – Schedule Update Deployment

Now we can get down with the nit and gritty of configuring deployment schedules based on your own requirement. This section will be configured down to personal preference for my Test Lab Machine.

Please Note:

The following information will only reference Windows Operating System, Linux is also available but will not be discussed.

Groups to update

In this section, you can filter the machines you would like to manage using Azure Update Management. This also includes the Non-Azure machines feature which is currently In Preview at the time of this post.

Azure Machines

If you select preview for your Azure Machines and unable to detect an clients. You may need onboard your Azure VM https://docs.microsoft.com/en-us/azure/automation/automation-onboard-solutions-from-vm

Non-Aure Machines

Machines to update

In this sectrion, depending how you are providing your client machines into the Azure Portal, you can use one of the three Types to select your machines

  • Saved Searches
  • Imported groups (AD,WSUS,SCCM)
  • Machines
Machines to update

Update classifications

In this section, you can select 8 individual classifications based on your requirements.

  • Critical updates
  • Security updates
  • Update rollups
  • Feature packs
  • Service packs
  • Definition updates
  • Tools
  • Updates

Select the type of update classifications you would like to apply to your client machines.

Include/Exclude updates

In this section you can Include or Exclude particular Microsoft update using the KB number without the KB prefix.

Schedule settings

In this section, you can specify the require schedule whether its run once or needs to recurrence cycle.

Pre-scripts + Post-scripts

In this section, Pre-scripts and Post-scripts are tasks that can be automatically executed before or after an update deployment run. You can configure up to one Pre-script and Post-script per deployment.

Finishing touches

Maintenance Window – To set the maintenance window, the duration must be a minimum of 30 minutes and less than 6 hours.
The last 20 minutes of the maintenance window is dedicated for machine restart and any remaining updates will not be started once this interval is reached. In-progress updates will finish being applied

Reboot options – There are currently 4 reboot options available

  • Reboot if required
  • Never reboot
  • Always reboot
  • Only reboot – will not install updates

Regards
The Author – Blogabout.Cloud

What is Global VNet Peering?

What is Global VNet Peering?

Global VNet Peering? This function has recently come to my attention while working with an international customer who is in the process of integrating into their new owners Azure Active Directory. Global VNet peering enables resources in your virtual network to communicate across Azure regions privately through the Microsoft backbone. Resources communicate directly, without gateways, extra hops, or transit over the public internet. This allows a high-bandwidth, low-latency connection across peered virtual networks in different regions.

Example of Vnet Peering between Regions

You can use Global VNet Peering to share resources within a global, private network. You can then easily replicate data across regions for redundancy and disaster recovery.

In my case I was integrating the Active Directory Domains and using Azure Active Directory Connector located in primary region to synchronize the AD Objects from one domain into the other. This approach provided a quick and simply migration without really complexity.

Global Vnet Peering is only currently supported for the following regions.

  • Americas: West Central US (Wyoming), West US 2 (Washington), Central US (Iowa), US East 2 (Virginia), Canada Central (Toronto), Canada East (Quebec City)
  • Asia Pacific: Southeast Asia (Singapore) Korea South (Buscan), South India (Chennai), Central India (Pune), West India (Mumbai)
  • Europe: UK South (London), UK West (Cardiff), West Europe (Netherlands)

Cost of VNET Peering within the same region

Inbound data transfer $0.01 per GB
Outbound data transfer $0.01 per GB

Cost of Global VNET Peering

Zone 1Zone 2Zone 3US Gov
Inbound data transfer $0.035 per GB $0.09 per GB $0.16 per GB $0.044 per GB
Outbound data transfer $0.035 per GB $0.09 per GB $0.16 per GB $0.044 per GB

Virtual Network TAP preview

Virtual Network TAP is a feature that allows customers to enable mirroring of their virtual machine network traffic to a packet collector.

GlobalUS Gov
VTAP $0.0125 per hour $0.0125 per hour

IP addresses

Public IP addresses, and reserved IP addresses can be used in services running inside a virtual network. They carry a nominal charge as outlined here

VPN Gateways

A virtual network can have one or more VPN gateways to connect back to on-premises network or other virtual networks in Azure. The VPN Gateway is charged as detailed here

Regards
The Author – Blogabout.Cloud

New functionality now in preview for Conditional Access

New functionality now in preview for Conditional Access

So I was happily minding my own business looking at the configuration of my Conditional Access and notice 3 new options have appeared;

  • Baseline policy: End user protection (Preview)
  • Baseline policy: Block legacy authentication (Preview)
  • Baseline policy: Require MFA for Service Management (Preview)

Baseline policy: End user protection (Preview)

This policy protects users by requiring multi-factor authentication (MFA) during risky sign-in attempts to all applications. Users with leaked credentials are blocked from signing in until a password reset.

Once the policy is enabled, users are required to register for MFA within 14 days of their first login attempt. The default method of MFA registration is the Microsoft Authenticator App.

This policy is either On or Off and you can also exclude users from receiving this policy

Baseline policy: Block legacy authentication (Preview)

This policy blocks all sign-ins using legacy authentication protocols that don’t support multi-factor authentication (such as IMAP, POP, SMTP). The policy does not block Exchange ActiveSync.

  • Office 2013 (without registry keys)
  • Office 2010
  • Thunderbird client
  • Legacy Skype for Business
  • Native Android mail client

This policy is either On or Off and you can also exclude users from receiving this policy. This policy is great as I have configured a custom built policy for just this but my policy also includes Exchange Active Sync.

Baseline policy: Require MFA for Service Management (Preview)

This policy requires users logging into services that rely on the Azure Resource Manager API to perform multi-factor authentication (MFA).

Services requiring MFA include:

  • Azure Portal
  • Azure Command Line Interface (CLI)
  • Azure PowerShell Module

This policy is either On or Off and you can also exclude users from receiving this policy

Its great to see some more brilliant developments in Conditional Access and really excited to see these go live with customers.

Regards
The Author – Blogabout.Cloud

Directory Based Edge Blocking in Exchange Online or (DBEB for short)

Directory Based Edge Blocking in Exchange Online or (DBEB for short)

What is DBEB? It is a solution that allows an organization to reject message for invalid recipient at the service network perimeter. DBEB enables your Office 365 Global Administrator to add mailed-enabled recipients to Office 365 and block all messages sent to email address that aren’t present in Office 365.

Valid messages are then subject to the rest of the service filtering layers which are;

Antimalware
Antispam
Mail Flow Rules (otherwise knows as Transport Rules)

Invalid messages are blocked before filtering even occurs, and a non-delivery report (also known as an NDR or bounce message) is returned to the sender. The NDR looks like this:

1
550 5.4.1 [<InvalidAlias>@\<Domain>]: Recipient address rejected: Access denied

Important Note

In hybrid environments, in order for DBEB to work, email for the domain must be routed to Office 365 first (the MX record for the domain must point to Office 365).

Configuring DBEB

First of all, you need to verify that your accepted domain EXO is an Internal Relay, this is done by going to Exchange Admin Console –> Mail Flow –> Accepted domains.

If, your domain type is Authoritative you will need to click the edit button and set to internal relay

Adding your users to Office 365

In the EAC, go back to Mail flow > Accepted domains.

Select the domain and click Edit.
Set the domain type to Authoritative.
Choose Save to save your changes, and confirm that you want to enable DBEB.

  • Until all of your valid recipients have been added to Exchange Online and replicated through the system, you should leave the accepted domain configured as Internal relay. Once the domain type has been changed to Authoritative, DBEB is designed to allow any SMTP address that has been added to the service (except for mail-enabled public folders). There might be infrequent instances where recipient addresses that do not exist in your Office 365 organization are allowed to relay through the service.
  • For more information about DBEB and mail-enabled public folders, see Office 365 Directory Based Edge Blocking support for on-premises Mail Enabled Public Folders.

Regards.
The Author – Blogabout.Cloud

Microsoft Teams Direct Routing with Azure Audiocodes SBC

Microsoft Teams Direct Routing with Azure Audiocodes SBC

Microsoft Teams Direct Routing is the latest in connecting your SIP trunk provider but how about leveraging the Microsoft cloud and deploy your Session Boarder Controller (SBC) into Azure.

Audiocodes are one of many SBC providers using Azure to provide an additional options with your approach to moving to Microsoft Teams.  If your a consultant deploying AudioCodes Mediant VE SBC for Microsoft Azure, this process couldnt be any easier with using Azure Resource Manager (ARM) templates which can be developed to adapt to any customer requirements.

If you have a bit of Azure knowledge in deploying new resources the below image will not be to difficult understand.

But if this is the first time you’ve looked deploying a resource in Azure, I highly recommend looking at creating a template and use Visual Studio. This will allow you to make modification in the code and learn how ARM templates work.

How much does the Audiocodes Virtual Machine cost?

The below tables is based on today costing as of 12 November 2018 and these prices may change.

VM Size Offering Family VCPU RAM Data Disk Max IOSP Temporay Storage SIP Sessions Price
D2_v2 Standard General Purpose 2 7 8 8×500 100GB 200 £75.41
D2_v3 Standard General Purpose 2 8 4 4×500 50GB 500 £66.54
D3_v2 Standard General Purpose 4 14 16 16×500 200GB 900 £150.83

Microsoft Teams Direct Routing will only get bigger as time goes on and you can expect the number of supported SIP sessions to increase (expected 6000 sessions in Q1 2019). It is also worth noting that Audiocodes also offer a multi tenant SBC so if you are a service provider, you can house multi customers on a single SBC appliance.

Regards

Author – Blogabout.Cloud

Dynamic groups in Microsoft Teams

Dynamic groups in Microsoft Teams

Microsoft Teams now supports dynamic groups but what does this mean? Dynamic groups are an Azure AD Premium (P1) feature that allows group membership to be automatically tied to AD attributes (i.e. users with a location of ‘London, New York or Seattle’) that will continuously sync as the membership changes over time. Dynamic group membership reduces the administrative overhead of adding and removing users.

Which is great for IT Administrator across the group.

How to create a dynamic group

Please follow the steps from here

https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-create-rule

Once you have created the group, every assigned member will receive an email stating they have joined the defined group

We already have a group (Office or Security) and would like to change its membership type to “Dynamic”

Of course you can do this from the Azure AD admin center. Please follow the steps from here https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-change-type

How do create a Microsoft Team with a Dynamic Group

Launch Microsoft Teams and click “Join or create a team

Click “Create a team from an existing Office 365 Group

Select the dynamic group you are an owner of and the group name will become the Team name.

Command Questions

Does this support syncing Security Groups (SGs)?

No, dynamic membership groups are different from SG/DL

How long does the dynamic group changes take to reflect in Teams?

This can take up to 2 hours after membership changes are reflected in Azure portal.

Regards,

Author – Blogabout.Cloud

Configuring Microsoft Intune – Apps within your company portal

Configuring Microsoft Intune – Apps within your company portal

Do you have one of the following licencing sets and you are not utilising Microsoft Intune? It would be criminal.

  • Intune
  • Enterprise Mobility + Security E3
  • Enterprise Mobility + Security E5
  • Microsoft 365 E3
  • Microsoft 365 E5
  • Microsoft 365 F1
  • Microsoft 365 Business
  • Microsoft 365 Education A1
  • Microsoft 365 Education A3
  • Microsoft 365 Education A5

Its time roll out the company portal and manage your corporate data across all mobile device.

Microsoft Intune is not available for the following licence sets and you need need to purchase one of the valid sets above.

  • Office 365 F1
  • Office 365 Business Premium
  • Azure Active Directory Free, Basic, Premium P1, Premium P2 None

Launch Microsoft Azure Portal

(https://portal.azure.com)

Open Intune either by using the Search resources, services, and docs or from your favourites. Select Client apps, Apps.

As you can see, there are no applications found currently within Client apps. In this section are able to define a number of different applications types with can be used whole Microsoft Intune platform.

For the purposes of this blog post we are only focusing on Other –> Built-In applications which have been optimised by Microsoft to ensure that all corporate data and general applications are secure.

Built-In applications target most of the Microsoft applications that are used day to day by all corporate enterprises. We will be selecting Adobe Acrobat Reader for Intune as an example of how to configure and publish applications into the company portal.

Click on your chosen app, press “Select” and press “Add”

Select Properties, App information – configure

Within this section you will need we will need configure the app information with the following

  • Category – This is not key but allows you group business, productivity, etc.. applications together
  • Display this as a feature app in the Compant Portal – Yes 
  • Logo – Give the application a logo which will appear in the company portal

Save the changes

Select Assignments, Add group

Under Assignment type, I have selected Available for enrolled devices.

Select Include Groups, Select Yes, Press OK x2 and Save

This will now make this application available within the company portal and you can repeat this process for other built-in applications.

 

This concludes this post

Regards

The Author – Blogabout.Cloud

Install PowerShell for Azure Stack

Install PowerShell for Azure Stack

Installing PowerShell for Azure Stack has a number of prerequistes which need to be met. The following script has been designed and tested to preform all the necessary tasks within a single script execution.

The following steps have been taken from https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-powershell-install

1. Verify your prerequisites

Before your get started with Azure Stack and PowerShell, you will need to have a few requirements in place.

PowerShell Version 5.0
To check your version, run $PSVersionTable.PSVersion and compare the Major version. If you do not have PowerShell 5.0, follow the link to upgrade to PowerShell 5.0.

Note

PowerShell 5.0 requires a Windows machine.

Run Powershell an elevated prompt
You will need to be able to run PowerShell with administrative privileges.

PowerShell Gallery access
You will need access to the PowerShell Gallery. The gallery is the central repository for PowerShell content. The PowerShellGet module contains cmdlets for discovering, installing, updating, and publishing PowerShell artifacts such as modules, DSC resources, role capabilities, and scripts from the PowerShell Gallery and other private repositories. If you are using PowerShell in a disconnected scenario, you will need to retrieve resources from a machine with a connection to the Internet and store them in a location accessible to your disconnected machine.

2. Validate if the PowerShell Gallery is accessible

Validate if PSGallery is registered as a repository.

Note

This step requires Internet access.

Open an elevated PowerShell prompt, and run the following cmdlets:
PowerShell

Import-Module -Name PowerShellGet -ErrorAction Stop
Import-Module -Name PackageManagement -ErrorAction Stop
Get-PSRepository -Name “PSGallery”

If the repository is not registered, open an elevated PowerShell session and run the following command:
PowerShell

Register-PsRepository -Default
Set-PSRepository -Name “PSGallery” -InstallationPolicy Trusted

3. Uninstall existing versions of the Azure Stack PowerShell modules

Before installing the required version, make sure that you uninstall any previously installed Azure Stack AzureRM PowerShell modules. You can uninstall them by using one of the following two methods:

To uninstall the existing AzureRM PowerShell modules, close all the active PowerShell sessions, and run the following cmdlets:
PowerShell

Uninstall-Module AzureRM.AzureStackAdmin -Force
Uninstall-Module AzureRM.AzureStackStorage -Force
Uninstall-Module -Name AzureStack -Force

Delete all the folders that start with Azure from the C:\Program Files\WindowsPowerShell\Modules and C:\Users\AzureStackAdmin\Documents\WindowsPowerShell\Modules folders. Deleting these folders removes any existing PowerShell modules.

4. Connected: Install PowerShell for Azure Stack with Internet connectivity

Azure Stack requires the 2017-03-09-profile API version profile, which is available by installing the AzureRM.Bootstrapper module. In addition to the AzureRM modules, you should also install the Azure Stack-specific PowerShell modules.

Run the following PowerShell script to install these modules on your development workstation:

Version 1.4.0 (Azure Stack 1804 or greater)
PowerShell

# Install the AzureRM.Bootstrapper module. Select Yes when prompted to install NuGet
Install-Module -Name AzureRm.BootStrapper

# Install and import the API Version Profile required by Azure Stack into the current PowerShell session.
Use-AzureRmProfile -Profile 2017-03-09-profile -Force

# Install Module Version 1.4.0 if Azure Stack is running 1804 at a minimum
Install-Module -Name AzureStack -RequiredVersion 1.4.0

Version 1.2.11 (before 1804)
PowerShell

# Install the AzureRM.Bootstrapper module. Select Yes when prompted to install NuGet
Install-Module -Name AzureRm.BootStrapper

# Install and import the API Version Profile required by Azure Stack into the current PowerShell session.
Use-AzureRmProfile -Profile 2017-03-09-profile -Force

# Install Module Version 1.2.11 if Azure Stack is running a lower version than 1804
Install-Module -Name AzureStack -RequiredVersion 1.2.11

Confirm the installation by running the following command:
PowerShell

Get-Module -ListAvailable | where-Object {$_.Name -like “Azs*”}

If the installation is successful, the AzureRM and AzureStack modules are displayed in the output.

All seems simple, right?

PowerShell script demonstration

The following video demonstrates the Set-AzureStackPS script, which is available to download via the following URL.

Download

PowerShell for Azure Stack (207 downloads)

Change Log

Version 1.1 – Features

  • Improved error detection for failed PowerShell module installation
  • Improved support for PSGallery detection
  • Improve code structure

Reporting Issues

If you identity any issues within running the script please email theauthor@blogabout.cloud

Regards

The Author – Blogabout.Cloud