Change account owner in Azure subscriptions

In every Azure subscription there are 2 built-in administrator roles. Both of them are sort of a Highlander (There can be only one).

Account Owner: The account owner is the person who registered or purchased the Azure subscription. This person has the right to access the Account Center and perform a variety of management tasks, such as creating subscriptions, canceling subscriptions, changing subscription billing details, or changing service administrators.

Service Administrator: The service administrator, which has the equivalent access of a user who is assigned the owner role at the subscription scope, manages services in the Azure portal and can assign users to the co-administrator role and RBAC roles.

Only the Account Owner can change the service administrator assignment.

Some times the need for changing account administrators arise. This is not a trivial task, so it must be carried out with caution.

The Account Owner must go to the Azure portal and select subscriptions, then select the subscription for which he is an owner. 

In the subscription blade, select Transfer Billing Ownership

Fill in the mail address of the new Account admin

Click Send Transfer Request

The Billing ownership recipient will now receive an e-mail, where the recipient needs to accept the transfer.

If the request is not accepted within 2 weeks time, the transfer is cancelled and the ownership is not transfered.

Then the recepient needs to accept the tranfer in the portal by ticking off the acceptance responsibility and click Accept ownership (Acceptér ejerskab).

Now the subscription account owner has been changed.

Network address table

When I am working with infrastructure techs at various customers, I often need to explain how subnetting is done in Azure, why you should do it and also how network addressing works. 

I have been inspired to create a network addressing cheat sheet where I can read the different address spaces available.

/24 255.255.255.0	/25 255.255.255.128	/26 255.255.255.192	/27 255.255.255.224	/28 255.255.255.240	/29 255.255.255.252
256 addresses 251 in Azure	128 addresses 123 in Azure	64 addresses 59 in Azure	32 addresses 27 in Azure	16 addresses 11 in Azure	8 addresses 3 in Azure
0 – 255	0 – 127	0 – 63	0 – 31	0 – 15	0 – 7
					8 – 15
				16 – 31	16 – 23
					24 – 31
			32 – 63	32 – 47	32 – 39
					40 – 47
				48 – 63	48 – 55
					56 – 63
		64 – 127	64 – 95	64 – 79	64 – 71
					72 – 79
				80 – 95	80 – 87
					88 – 95
			96 – 127	96 – 111	96 – 103
					104 – 111
				112 – 127	112 – 119
					120 – 127
	128 – 255	128 – 191	128 – 159	128 – 143	128 – 135
					136 – 143
				144 – 159	144 – 151
					152 – 159
			160 – 191	160 – 175	160 – 167
					168 – 175
				176 – 191	176 – 183
					184 – 191
		192 – 255	192 – 223	192 – 207	192 – 199
					200 – 207
				208 – 223	208 – 215
					216 – 223
			224 – 255	224 – 239	224 – 231
					232 – 239
				240 – 255	240 – 247
					248 – 255

I often use this table for visualizing which network addresses are available in different address scopes.

Extending corporate network to untrusted device using Windows 10 and how to prevent it

At a customer site I discovered patterns of unexpected network traffic to various Google and Apple sites. The policy doesn't allow for unmanaged devices (BOYD mobile phones etc. til access the WiFi network, and this traffic pattern looks like mobile devices, but there weren't any mobile devices associated on the wifi.

What actually happened is that dual radio Windows 10 devices are able to have a Mobile Hotspot where mobile phones connects on 5GHz while maintaining a WiFi connection on 2.4GHz. This allows unmanaged devices to access the corporate network.

To prevent this "feature", we decided to disable Mobile Hotspot sharing on the Windows 10 devices. Using Intune device configuration we used this setting:

Setting this entry: ./Vendor/MSFT/Policy/Config/WiFi/AllowInternetSharing to 0 disables the Mobile Hotspot button on Windows 10 devices.

Azure ATP sensor not starting

In one of my customers Azure ATP dashboard this health error has emerged:

On the domain controller in question, the Azure ATP Sensor (aatpsensor) service was in a starting loop and event 7031 was flooding the System eventlog.

Having a look at the Microsoft.Tri.Sensor-Errors.log file (in %programfiles%\Azure Advanced Threat Protection Sensor\<version>\Logs\), the problem is indicated:

Error WinPcapDeviceList SharpPcap.PcapException: No interfaces found! Make sure libpcap/WinPcap is properly installed on the local machine.

WinPcap... as the one from Wireshark?? Indeed. 

Wireshark is installed on the domain controller with the sensor problem, it is not needed anymore, so I uninstalled all Wireshark components and the Azure ATP Sensor and reinstalled the Azure ATP sensor. 

Now the sensor works again.

There is an issue with running Wireshark on the domain controller where Azure ATP Sensor is installed, as the WinPcap component is used by both applications.

Teams naming policy

I have come across a few organizations, where the creation of new teams in Microsoft Teams is limited to a few administrators. This is off course a method to make sure the administrators still have work to do, but a rather ineffective way to control the names being used.

As you might know, when creating a Teams team an Office 365 Group, a Sharepoint site, and a mailbox is created as well.

In this case we want to make sure any Teams team created is following this naming policy:
"Team [GroupName] [Company] [Department]", so if a user from Engineering in Contoso creates a team called ProjectX, the name of the Teams team will be: "Team ProjectX Contoso Engineering".

Supported Azure AD attributes are [Department], [Company], [Office], [StateOrProvince], [CountryOrRegion] and [Title]. [GroupName] is a mandatory entry in the policy.

1. Make sure you have the newest AzureADPreview Powershell module installed.

Uninstall-Module AzureADPreview
Install-Module AzureADPreview

2.
Import the module and connect to Azure AD.

Import-Module AzureADPreviewConnect-AzureAD

Sign-in to your account.

3. Fetch the current settings

$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id
$Setting.Values

If the $Setting.Values returns an entry proceed to step 5

4.
Get the settings template

$Template = Get-AzureADDirectorySettingTemplate -Id
(Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id

Create a new settings object based o the template

$Setting = $template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $setting 

5.
Save the setting for the team naming policy

$Setting["PrefixSuffixNamingRequirement"] =“Teams [GroupName] [Company] [Department]"
Set-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id -DirectorySetting $Setting

That´s it.
Now we can see the new PrefixSuffixNamingRequirement is in place

(Get-azureADDirectorySetting | Where-Object {$_.displayname -eq "Group.Unified"}).values

Our next problem is no one is allowed to use the word ProjectX in our Teams. Also words as CEO, NextLevel and payroll is not accepted.

Fetch the settings again.

$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id

Set the blocked words list - the words are case insensitive, note that substrings are not checked, so Class will be permitted even is Lass is blocked.

$Setting["CustomBlockedWordsList"]=“ProjectX,CEO,NextLevel,payroll"

And save the settings again

Set-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id -DirectorySetting $Setting

Now also the BlockedWords List is updated.

All these settings are also available in the Azure portal now.

When a user creates a new team, this is the user experience in Teams.

When a user tries to create a new team with a blocked word, like ProjectX.

Tenant dialplan for Danish users

The default Office 365 dialplan doesn't offer a correct national translation for the Danish based user (based on location in Office 365) to E.164.

Example:

The official Danish numbering plan has the following general properties:
00 - International Access Code (rule3)
0[1-9] - Not in use
10 - Operator specific routing codes 
1[1-9] - 3-5 digit short dials (like emergency service 112, police 114 etc.) (rule1)
2-9 - 8 digit landline and mobile phonenumbers (rule2)

Special numbers are numbers starting with 80 (toll-free) and 90 (overpriced).

For more information on the numbering plant, please visit Energistyrelsen (Danish Energy Agency): https://ens.dk/ansvarsomraader/telefoni/numre/den-danske-nummerplan 

To support the Danish numbering dialplan, a tenant dialplan has to be created.

These cmdlets will support a Global tenant dialplan:
$rule1 = New-CsVoiceNormalizationRule -Name 'DK - service' -Parent 'Global' -Pattern '^(1\d{2,4})$' -Translation '+45$1' -Priority 2 -InMemory
$rule2 = New-CsVoiceNormalizationRule -Name 'DK - national' -Parent 'Global' -Pattern '^([2-9]\d{7})$' -Translation '+45$1' -Priority 3 -InMemory
$rule3 = New-CsVoiceNormalizationRule -Name 'DK - international' -Parent 'Global' -Pattern '^00(\d+)' -Translation '+$1' -Priority 4 -InMemory
Set-CsTenantDialPlan -Identity 'Global' -NormalizationRules @{add=$rule1,$rule2,$rule3}

And grant this dialplan to the user:
Grant-CsTenantDialPlan -Identity <userid> -PolicyName 'DK'

You could also include a voice normalization rule for internal numbers (old telephony style) - this one will support 4 digits in the range of 4200-4399 and translate to +457874xxxx:

$rule = New-CsVoiceNormalizationRule -Name 'DK - intern' -Parent 'Global' -Pattern '^(4[2-3]\d{2})$' -Translation '+457874$1' -Priority 1 -InMemory

If you have users in multiple countries, you should create a country specific tenant dialplan.
$rule1 = New-CsVoiceNormalizationRule -Name 'DK - service' -Parent 'Global' -Pattern '^(1\d{2,4})$' -Translation '+45$1' -Priority 2 -InMemory
$rule2 = New-CsVoiceNormalizationRule -Name 'DK - national' -Parent 'Global' -Pattern '^([2-9]\d{7})$' -Translation '+45$1' -Priority 3 -InMemory
$rule3 = New-CsVoiceNormalizationRule -Name 'DK - international' -Parent 'Global' -Pattern '^00(\d+)' -Translation '+$1' -Priority 4 -InMemory
New-CsTenantDialPlan -Identity 'DK' -NormalizationRules @{add=$rule1,$rule2,$rule3}

This could also be scripted based on the user location:

Connect-MsolService

$users = Get-MsolUser | Where-Object {$_.UsageLocation -eq 'DK'}

foreach ($user in $users)

{

Grant-CsTenantDialPlan -Identity $user.UserPrincipalName -PolicyName 'DK'

}

As always, please share your thoughts, on this topic, below.