Configuring Writeback Permissions in Active Directory for Azure Active Directory Sync

Posted on 40 CommentsPosted in 2008, 2008 R2, 2012, 2012 R2, active directory, ADFS 3.0, Azure, Azure Active Directory, cloud, exchange, exchange online, groups, hybrid, IAmMEC, Office 365, WAP, Web Application Proxy, windows

[Update March 2017 – added another blog post on using the below to fix permission-issue errors on admin and other protected accounts at http://c7solutions.com/2017/03/administrators-aadconnect-and-adminsdholder-issues]

[This blog post was last updated 18th June 2017 in advance of the release of AADConnect version 1.1.553.0. This post contains updates to the below scripts to include the latest attributes synced back to on-premises]

Azure Active Directory has been long the read-only cousin of Active Directory for those Office 365 and Azure users who sync their directory from Active Directory to Azure Active Directory apart from eight attributes for Exchange Server hybrid mode. Not any more. Azure Active Directory writeback is now available and in preview for some of the writeback types at the time of writing. This enabled objects to be mastered or changed in Azure Active Directory and written back to on-premises Active Directory.

This writeback includes:

  • Devices that can be enrolled with Office 365 MDM or Intune, which will allow login to AD FS controlled resources based on user and the device they are on
  • “Modern Groups” in Office 365 can be written back to on-premises Exchange Server 2013 CU8 or later hybrid mode and appear as mail enabled distribution lists on premises. Does not require AAD Premium licences
  • Users can change their passwords via the login page or user settings in Office 365 and have that password written back online.
  • Exchange Server hybrid writeback is the classic writeback from Azure AD and is the apart from Group Writeback is the only one of these writebacks that does not require Azure AD Premium licences.
  • User writeback from Azure AD (i.e. users made in Office 365 in the cloud for example) to on-premises Active Directory
  • Windows 10 devices for “Azure AD Domain Join” functionality

All of these features (apart from Exchange Hybrid writeback) require AADConnect and not and of the earlier verions (which will be actively blocked by the end of 2017 anyway). Install and run the AADConnect program to migrate from DirSync to AADSync and then in the Synchronization Options on rerunning the AADConnect wizard you can add all these writeback functions.

In all the below sections you need to grant permission to the connector account. You can find the connector account for your Active Directory forest from the Synchronization Service program > Connectors > double-click your domain > select Connect to Active Directory Forest. The account listed here is the connector account you need to grant permissions to.

SourceAnchor Writeback

For users with (typically) multi-forest deployments or plans or a forest migration, the objectGuid value in Active Directory, which is used as the source for the attribute that keys your on-premises object to your synced cloud object – in AAD sync parlance, this is known as the SourceAnchor. If you set up AADConnect version 1.1.553.0 or later you can opt to change from objectGuid to a new source anchor attribute known as ms-ds-consistencyGuid. To be able to use this new feature you need the ability for AADConnect connector account to be able to read ObjectGUID and then write it back to ms-ds-consistencyGuid. The read permissions are typically available to the connector account without doing anything special, and if AADConnect is installed in Express Mode it will get the write permissions it needs, but as with the rest of this blog, if you are not using Express Mode you need to grant the permissions manually and so write permissions are needed to the ms-ds-consistencyGuid attribute. This can be done with this script.


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$ForestDN = "DC=contoso,DC=com"

$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd | Out-Null

Note that if you use ms-ds-consistencyGuid then there are changes required on your ADFS deployment as well. The Issuance Transform Rules for the Office 365 Relying Party Trust contains a rule that specifies the ImmutableID (aka AADConnect SourceAnchor) that the user will be identified as for login. By default this is set to ObjectGUID, and if you use AADConnect to set up ADFS for you then the application will update the rule. But if you set up ADFS yourself then you need to update the rule.

Issuance Transform Rules

When Office 365 is configured to federate a domain (use ADFS for authentication of that domain and not Azure AD) then the following are the claims rules that exist out of the box need to be adjusted. This is to support the use of ms-ds-consistencyguid as the immutable ID.

ADFS Management UI > Trust Relationships > Relying Party Trusts

Select Microsoft Office 365 Identity Platform > click Edit Claim Rules

You get two or three rules listed here. You get three rules if you use -SupportMultipleDomain switch in Convert-MSOLDomainToFederated.
Rule 1:
Change objectGUID to ms-DS-ConsistencyGUID
Rule Was:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,objectGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);
New Value:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,ms-DS-ConsistencyGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);

Preparing for Device Writeback

If you do not have a 2012 R2 or later domain controller then you need to update the schema of your forest. Do this by getting a Windows Server 2012 R2 ISO image and mounting it as a drive. Copy the support/adprep folder from this image or DVD to a 64 bit domain member in the same site as the Schema Master. Then run adprep /forestprep from an admin cmd prompt when logged in as a Schema Admin. The domain member needs to be a 64 bit domain joined machine for adprep.exe to run.

Wait for the schema changes to replicate around the network.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Azure AD Global Admin and Enterprise Admin permissions for Azure and local AD forest respectively. The cmdlets for this are obtained by running the Azure AD Connect tool.


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
Initialize-ADSyncDeviceWriteBack -AdConnectorAccount $accountName -DomainName contoso.com #[domain where devices will be created].

This will create the “Device Registration Services” node in the Configuration partition of your forest as shown:

image

To see this, open Active Directory Sites and Services and from the View menu select Show Services Node. Also in the domain partition you should now see an OU called RegisteredDevices. The AADSync account now has permissions to write objects to this container as well.

In Azure AD Connect, if you get the error “This feature is disabled because there is no eligible forest with appropriate permissions for device writeback” then you need to complete the steps in this section and click Previous in the AADConnect wizard to go back to the “Connect your directories” page and then you can click Next to return to the “Optional features” page. This time the Device Writeback option will not be greyed out.

Device Writeback needs a 2012 R2 or later AD FS server and WAP to make use of the device info in the Active Directory (for example, conditional access to resources based on the user and the device they are using). Once Device Writeback is prepared for with these cmdlets and the AADConnect Synchronization Options page is enabled for Device Writeback then the following will appear in Active Directory:

image

Not shown in the above, but adding the Display Name column in Active Directory Users and Computers tells you the device name. The registered owner and registered users of the device are available to view, but as they are SID values, they are not really readable.

If you have multiple forests, then you need add the SCP record for the tenant name in each separate forest. The above will do it for the forest AADConnect is installed in and the below script can be used to add the SCP to other forests:

$verifiedDomain = "contoso.com"  # Replace this with any of your verified domain names in Azure AD
$tenantID = "27f998bf-86f2-41bf-91ab-2d7ab011df35"  # Replace this with you tenant ID
$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=com"  # Replace this with your AD configuration naming context
$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()

Preparing for Group Writeback

Writing Office 365 “Modern Groups” back to Active Directory on-premises requires Exchange Server 2013 CU8 or later schema updates and servers installed. To create the OU and permissions required for Group Writeback you need to do the following.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Domain Admin permissions for the domain in the local AD forest that you will write back groups to. The cmdlets for this are obtained by running the Azure AD Connect tool.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$cloudGroupOU = "OU=CloudGroups,DC=contoso,DC=com"
Initialize-ADSyncGroupWriteBack -AdConnectorAccount $accountName -GroupWriteBackContainerDN $cloudGroupOU

Once these cmdlets are run the AADSync account will have permissions to write objects to this OU. You can view the permissions in Active Directory Users and Computers for this OU if you enable Advanced mode in that program. There should be a permission entry for this account that is not inherited from the parent OU’s.

At the time of writing, the distribution list that is created on writeback from Azure AD will not appear in the Global Address List in Outlook etc. or allow on-premises mailboxes to send to these internal only cloud based groups. To add it to the address book you need to create a new subdomain, update public DNS and add send connectors to hybrid Exchange Server. This is all outlined in https://technet.microsoft.com/en-us/library/mt668829(v=exchg.150).aspx. This ensure’s that on-premises mailboxes can deliver to groups as internal senders and not require external senders enabled on the group. To add the group to the Global Address List you need to run Update-AddressList in Exchange Server. Once group writeback is prepared for using these cmdlets here and AADConnect has had it enabled during the Synchronization Options page, you should see the groups appearing in the selected OU as shown:

image

And you should find that on-premises users can send email to these groups as well.

Preparing for Password Writeback

The option for users to change their passwords in the cloud and have then written back to on-premises (with multifactor authentication and proof of right to change the password) is also available in Office 365 / Azure AD with the Premium Azure Active Directory or Enterprise Mobility Pack licence.

To enable password writeback for AADConnect you need to enable the Password Writeback option in AADConnect synchronization settings and then run the following three PowerShell cmdlets on the AADSync server:


Get-ADSyncConnector | fl name,AADPasswordResetConfiguration
Get-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD"
Set-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD" -Enable $true

The first of these cmdlets lists the ADSync connectors and the name and password reset state of the connector. You need the name of the AAD connector. The middle cmdlet tells you the state of password writeback on that connector and the last cmdlet enables it if needed. The name of the connector is required in these last two cmdlets.

To set the permissions on-premises for the passwords to be written back the following script is needed:

$passwordOU = "DC=contoso,DC=com" #[you can scope this down to a specific OU]
$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Reset Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Change Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;lockoutTime;user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;pwdLastSet;user'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for Exchange Server Hybrid Writeback

Hybrid mode in Exchange Server requires the writing back on eight attributes from Azure AD to Active Directory. The list of attributes written back is found here. The following script will set these permissions for you in the OU you select (or as shown at the root of the domain). The DirSync tool used to do all this permissioning for you, but the AADSync tool does not. Therefore scripts such as this are required. This script sets lots of permissions on these eight attributes, but for clarify on running the script the output of the script is sent to Null. Remove the “| Out-Null” from the script to see the changes as they occur (the script also takes a lot longer to run).

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$HybridOU = "DC=contoso,DC=com"

#Object type: user
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;user'"
Invoke-Expression $cmd | Out-Null

#Object type: iNetOrgPerson
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null

#Object type: group
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;group'"
Invoke-Expression $cmd | Out-Null

#Object type: contact
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;contact'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for User Writeback

[This functionality is not in the current builds of AADConnect]

Currently in preview at the time of writing, you are able to make users in Azure Active Directory (cloud users as Office 365 would call them) and write them back to on-premises Active Directory. The users password is not written back and so needs changing before the user can login on-premises.

To prepare the on-premises Active Directory to writeback user objects you need to run this script. This is contained in AdSyncPrep.psm1 and that is installed as part of Azure AD Connect. Azure AD Connect will install Azure AD Sync, which is needed to do the writeback. To load the AdSyncPrep.psm1 module into PowerShell run Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$cloudUserOU = "OU=CloudUsers,DC=contoso,DC=com"
Initialize-ADSyncUserWriteBack -AdConnectorAccount $accountName -UserWriteBackContainerDN $cloudUserOU

Once the next AADSync occurs you should see users in the OU used above that match the cloud users in Office 365 as shown:

image

Prepare for Windows 10 Registered Device Writeback Sync

Windows 10 devices that are joined to your domain can be written to Azure Active Directory as a registered device, and so conditional access rules on device ownership can be enforced. To do this you need to import the AdSyncPrep.psm1 module. This module supports the following two additional cmdlets to prepare your Active Directory for Windows 10 device sync:

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1
Initialize-ADSyncDomainJoinedComputerSync
Initialize-ADSyncNGCKeysWriteBack

These cmdlets are run as follows:

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$azureAdCreds = Get-Credential #[Azure Active Directory administrator account]

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1
Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount $accountName -AzureADCredentials $azureAdCreds 
Initialize-ADSyncNGCKeysWriteBack -AdConnectorAccount $accountName 

Once complete, open Active Directory Sites and Services and from the View menu Show Services Node. Then you should see the GUID of your domain under the Device Registration Configuration container.

image

Access Is Denied Message After Sysprep–How To Fix

Posted on 1 CommentPosted in 2003, 2007, 2008, 2008 R2, 2012, 64 bit, backup, bios, hyper-v, password, recovery, sysprep, windows, windows 2003, windows 2008, windows 7, windows server, workstation, x64, x86

If before you use Sysprep to prepare a Windows machine for imaging you set the administrators password “User cannot change password” then sysprep will not clear this setting, but will set the “User must change password at next logon” setting. Normally these two settings are mutually exclusive, but in the scenario for sysprep it seems they can both end up being set.

This means you get prompted to reset you password at first logon after sysprep completes and then find you have “Access Denied” as the response. There is seemingly no way around this Catch-22.

That is unless you use the Offline NT Password and Registry Editor. This tool allows password resets when booting the server from a CD or USB key (so physical access to the server is required). As the download for this is an iso file, it can also be used in virtual environments by configuring your virtual machine to boot from the iso you have downloaded.

To allow you to logon to your machine following the above issue, all you need to in the Offline NT Password tool is to blank out the administrators password and unlock the account. These are options 1 and 4 during the password reset stage. Full instructions with screenshots follow:

  1. Boot the server with the issue with the Offline NT Password and Registry Editor iso file:
    image
  2. Choose the correct boot option (or just press Enter for the defaults):
    image
  3. For Vista and earlier select the default of Option 1. For Windows 7 and Windows 2008 and later select Option 2 (to boot into the second partition on the disk). You might need to select a different option if you have more partitions. You need to select the partition that Windows is installed on.
  4. If the disk is marked as Read-Only ensure that the server went through a clean boot and was not shutdown incorrectly. Once the messages indicate a writable partition
    image
  5. Select the presented folder (by pressing Enter again). You can typically just press Enter through most of these stages. You will be asked what you want to do – we want to reset passwords:
    image
  6. Select Option 1 to Edit user data and passwords:
    image
  7. Press Enter to choose the Administrator account:
    image
  8. Type 1 to Clear (blank) user password. You should get back the message “Password cleared!”:
    image
  9. Press Enter again to reselect the Administrator account, and this time select Option 4 to unlock the account (even though this program tells you the account is already unlocked):
    image
  10. Once you see “Unlocked!” you can quit from this program. The process to quit requires you to save your changes. Note that the default setting is not to save changes, so you cannot now use Enter to select the default option.
  11. Enter ! to quit from the password reset program:
    image
  12. Enter q to quit from the script and to ask about saving changes:
    image
  13. Enter y to write back the files that have been changed:
    image
  14. You should have been told “***** EDIT COMPLETE *****”. Press Enter to finish the program scripts:
    image
  15. At this final screen you can remove the CD or unmount the iso image from your virtual machine and press CTRL+ALT+DEL to restart the server. The server should now boot into Windows and auto-logon as it has a blank password.
  16. Change the password and optionally untick the “User cannot change password” setting.

Building An Exchange Unified Messaging Lab (Part 7)

Posted on Leave a commentPosted in 2008, 2010, 2013, asterisknow, exchange, rtp, sip, unified messaging, voicemail

In this series of blog posts I am looking at creating a Unified Messaging lab for Exchange Server 2010 (and 2013). Earlier posts have looked at the installation of the PBX (AsteriskNOW) and the configuration of the Exchange Server.

This post will look at the configuration of the user’s settings. For each user there are two settings to configure. The first are the related settings on the telephone and the second is the configuration of the unified messaging properties on the Exchange mailbox.

The first set of settings are covered in detail in Part 4 of the blog but in brief they involve choosing a unique extension number that has the same number of digits as the dialplan (all extensions must be unique within the dialplan) and creating this extension within the PBX and configuring a phone to use this extension. Once you have done the steps in Part 4 of the blog you should be able to ring any of your extensions and pickup the call.

If you ignore the call or press any “reject” button on the handset you will find that Asterisk voicemail answers the phone. So this part of the blog series will go into the steps to configure Asterisk to forward voicemail to Exchange Server (and this is the same for Exchange Server 2010 or 2013).

Configuring Unified Messaging Mailboxes in Exchange Server

For each user you need to associate their mailbox in Exchange with their extension number. You can do with the Enable-UMMailbox cmdlet or the Enable Unified Messaging wizard in the Exchange Management Console.

For the wizard, right-click the mailbox under Recipient Configuration and select the Unified Messaging Mailbox Policy that you created earlier. Then either choose a PIN or have the system generate on for the user automatically. The user will get an email informing them of their PIN either way. Click Next.

imageIf the user already has the Business Phone attribute (or Telephone number attribute on the General tab in Active Directory Users and Computers) populated in Active Directory then the option to automatically generate the mailbox extension will be available, and the extension will be shown (greyed out) in the field to the right. If this is incorrect, or a full phone number was not specified, then only the manual option will be available.

The Exchange Management Shell cmdlet to do the same is:

Enable-UMMailbox username -PinExpired $false -UMMailboxPolicy 'policy_name'

 

 

or, if you want to specify the extension number:

 

Enable-UMMailbox username -PinExpired $false -UMMailboxPolicy 'policy_name' -Extensions '8001'

 

 

As each mailbox is enabled for unified messaging, the mailbox will get an email telling them the access numbers for voicemail (the dialplan subscriber numbers), their number (which should be the same as their telephone extension number) and their PIN.

 

On the mailbox, if you look on the E-mail Addresses tab you will see the EUM address, and this should read ext;phone-content=policy. You can add additional extensions (EUM addresses) here manually if you wish.

 

Configuring and Using Outlook Voice Access

 

Now that you have the extension configured on a phone, the same extension configured against the mailbox, a dialplan with subscriber access number configured, SIP trunks to Exchange and an Outbound Route for the subscriber access number you should be able to ring the subscriber access number from your physical handset.

 

Upon dialling from the phone configured with your extension number you will hear the Exchange chimes and be asked to setup your Outlook Voice Access for the first time. You will need your PIN number to complete this, and this will have been emailed to the mailbox at the time the mailbox was configured for UM.

 

Configure Asterisk to Forward Calls to Exchange Unified Messaging for Voicemail

 

Asterisk defaults to forwarding calls to its own voicemail extensions and so edits need to be made to extensions.conf (or linked files if using FreePBX) to route calls to Exchange Server for voicemail.

 

In this blog series we have FreePBX installed, so we need to edit /etc/asterisk/extensions_override_freepbx.conf rather than extensions.conf. The first change is to copy the [macro-vm] section from /etc/asterisk/extensions_additional.conf into /etc/asterisk/extensions_override_freepbx.conf. [macro-vm] is approx 150 lines long and ends with “;–== end of [macro-vm] ==–;”.

 

Then we need to make some changes and additions to the macro-vm section. The first set of changes will comment out the code the directs calls to Asterisk voicemail and the additional lines will dial the Exchange Server trunks and add SIP Diversion headers so that Exchange knows which mailbox to answer the call for.

 

So first, locate the following lines and comment them out. The numbers in brackets at the start are the approx. location in extensions_override_freepbx.conf where you will find the line:

(86) exten => s-BUSY,n,VoiceMail(${MEXTEN}@${VMCONTEXT},${VM_OPTS}b${VMGAIN})
(92) exten => s-NOMESSAGE,n,VoiceMail(${MEXTEN}@${VMCONTEXT},s${VM_OPTS}${VMGAIN})
(97) exten => s-DIRECTDIAL,n,VoiceMail(${MEXTEN}@${VMCONTEXT},${VM_OPTS}${VM_DDTYPE}${VMGAIN})

 

Each of the above lines can be commented out by placing a semi-colon (;) at the start of the line.

 

Return to the s-BUSY block (starting at line 84) and add the following after the line that you just commented out:

exten => s-BUSY,n,SIPAddHeader(Diversion:<tel:${MEXTEN}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s-BUSY,n,Dial(SIP/xxxx&SIP/yyyy) /* xxxx/yyyy here are the two trunk names, one for each TCP listening port */
exten => s-BUSY,n,Hangup

 

This code adds the Diversion header to read tel:extension. Note that the tel:ext block is surrounded by greater and less than signed (triangle brackets if you will) which have a habit of not being displayed on web pages.

 

Also note that you need to use the names of your two trunks connecting to Exchange that you will make in the final part of this blog series (Part 8). You will make one trunk connecting to port 5065 and the other to port 5067. The Dial() command tells Asterisk to dial both trunks at the same time and direct the call to whichever answers first. Therefore if Exchange is listening on 5065 or 5067 the connection will work. For ease of configuration, if you pick the names for the two trunks now you can add them to the config file here and then when you create the trunk in Part 8 you just need to use the same names. I used ToExchangeUM5065 and ToExchangeUM5067 in my lab. Then I replace xxxx with ToExchangeUM5065 and yyyy with ToExchangeUM5067.

 

The s-NOMESSAGE block (at line 92) needs the following added after the line that has been commented out:

exten => s-NOMESSAGE,n,SIPAddHeader(Diversion:<tel:${MEXTEN}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s-NOMESSAGE,n,Dial(SIP/xxxx&SIP/yyyy) /* xxxx/yyyy here are the two trunk names, one for each TCP listening port */
exten => s-NOMESSAGE,n,Hangup

 

Again, change xxxx and yyyy for your two different trunk names that you create in the next part of this blog and make sure that the Diversion: header includes triangle brackets around tel:ext.

 

Next you need to do the same for the s-DIRECTDIAL block:

exten => s-DIRECTDIAL,n,SIPAddHeader(Diversion:<tel:${MEXTEN}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s-DIRECTDIAL,n,Dial(SIP/xxxx&SIP/yyyy) /* xxxx/yyyy here are the two trunk names, one for each TCP listening port */
exten => s-DIRECTDIAL,n,Hangup

 

As you can see, the three blocks of inserted code are all the same apart from the s-WORD value at the start of each.

 

One block of code is missing through from the FreePBX defaults. If you call an extension and it is busy Asterisk runs the code starting s-BUSY, but if the call is ignored then Asterisk attempts to find and run code starting s-NOANSWER and as this is missing it will route ignored calls to Asterisk voicemail. To route ignored calls to Exchange Server add the following block of text:

exten => s-NOANSWER,1,Noop(NOANSWER voicemail - Exchange UM)
exten => s-NOANSWER,n,Macro(get-vmcontext,${MEXTEN})
exten => s-NOANSWER,n,SIPAddHeader(Diversion:<tel:${MEXTEN}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s-NOANSWER,n,Dial(SIP/xxxx&SIP/yyyy) /* xxxx/yyyy here are the two trunk names, one for each TCP listening port */
exten => s-NOANSWER,n,Hangup
exten => s-NOANSWER,n,Goto(exit-${VMSTATUS},1)

 

This new block is again a copy of s-BUSY (or the other two) and just the s-WORD bit changed to s-NOANSWER. For completion the Noop line (line 1 above) is also changed to NOANSWER so that the correct text is written to the Asterisk console and log files.

 

No other changes are needed in extensions_override_freepbx.conf. So save the file and restart Asterisk by using amportal restart from the console.

 

There is now one more thing to do. That is to create the SIP Trunks to Exchange Server. This is detailed in Part 8, and once you have a way to connect to Exchange Server you are able to route voicemail requests to Exchange and complete your unified messaging lab.

Installing Dell Open Manage 7.1 on Hyper-V R2 Servers

Posted on Leave a commentPosted in 2008, 2008 R2, 2012, dell, hyper-v, openmanage, osma, server administrator, server core, windows server

This set of instructions goes through the process for installing Dell Open Manager on Windows Server 2008 R2 and Windows Server 2012.

  1. Download both the 6.5 and 7.1 versions of Dell Open Manage
    • You need to install 6.5 first, or you will get errors about “omchecks has stopped working” failing during the RunPreReqChecks process and an error about “Failed to load OMIL Library” when running the actual installer.

image

image

  1. On the server run Dism /online /enable-feature /featurename:SNMP-SC to install SNMP
  2. After downloading 6.5 expand the zip to c:\OpenManage65 and if needed copy to the server you are installing on, or burn a DVD and insert it into the server in question.
  3. Install Open Manage 6.5 with the following steps
    1. cd c:\OpenManage65\windows\prereqchecker
    2. runprereqchecks /s
    3. echo Return Code = %ERRORLEVEL%
    4. Check the Return Code with the codes listed at http://support.dell.com/support/edocs/software/smsom/6.1/en/ug/HTML/prereqch.htm#wp1053477
    5. Fix any errors listed. You should get a 2 as the Return Code. You might need to view the prereqchecker HTML file that it creates. This is made in your temp directory. Cd %TEMP% to see what this is. It will be something like c:\Users\username\AppData\Local\Temp\2. To open the HTML output file connect to this temp folder from a machine with IE installed on it and open omprereq.htm. Fix any listed errors.
    6. cd c:\OpenManage65\windows\SystemsManagement
    7. msiexec /i SysMgmt.msi
    8. Choose Custom and add the Remote Enablement option.
  4. Allow remote access to TCP port 1311 (the Open Manage web server port) using netsh advfirewall firewall add rule name="Dell OpenManage Server Administrator Web GUI" dir=in action=allow protocol=TCP localport=1311
  5. Install Open Manage 7.1. The steps here are similar, just from the directory containing version 7.1 instead.
    1. cd c:\OpenManage71\windows\prereqchecker
    2. runprereqchecks /s
    3. echo Return Code = %ERRORLEVEL%
    4. Check the Return Code with the codes listed at http://support.dell.com/support/edocs/software/smsom/6.1/en/ug/HTML/prereqch.htm#wp1053477
    5. Fix any errors listed. You should get a 2 as the Return Code. You might need to view the prereqchecker HTML file that it creates. This is made in your temp directory. Cd %TEMP% to see what this is. It will be something like c:\Users\username\AppData\Local\Temp\2. To open the HTML output file connect to this temp folder from a machine with IE installed on it and open omprereq.htm. Fix any listed errors.
    6. cd c:\OpenManage71\windows\SystemsManagement
    7. msiexec /i SysMgmt.msi
    8. Choose Custom and add the Remote Enablement option (though as this is now an upgrade it should already be selected).
  6. Finish by browsing to https://remoteserver:1311 not forgetting the s in https. You will get a certificate error and once connected you can replace this if you wish or are required to by corporate policies.
  7. With thanks to the following two blogs:

    Scheduling Backup on Microsoft Hyper-V Server

    Posted on 2 CommentsPosted in 2008, 2008 R2, backup, hyper-v

    To do a backup of the virtual machines installed on your Hyper-V Server (2008 or 2008 R2 editions) you need to complete the following steps.

    1. Install the backup feature by typing start /w ocsetup WindowsServerBackup from the command prompt.
    2. Get a list of the drives on which Hyper-V Server has stored virtual machines. This will be C: unless you have made changes.
    3. Determine the times you want to run the backup at.
    4. Determine the drive letter of the removable disk by typing at the command prompt each of the following commands
      1. diskpart
      2. list volume
      3. The disk drive letter will be displayed for the disk that matches the size of your removable disk.
      4. Type exit to exit diskpart.
    5. From the command prompt type wbadmin enable backup -addtarget:x: -schedule:hh:mm,h2:m2 -include:y:,z: -systemState -allCritical to backup to drive X: the contents of drives Y: and Z:, the system state and all drives critical to the running of the server.
    6. Confirm you want to schedule the backup at times HH:MM and H2:M2 (for twice a day). If you want one backup a day use HH:MM and if you want more than two just comma separate a group of times. Enter times as per local timezone. Check the current time on the Hyper-V Server by typing time from the command prompt.
    7. Start a backup now if you want by typing wbadmin start backup and confirming to use the same settings as the scheduled backup.
    8. Backup will proceed in the console. If you log out backup will remain running.
    9. Enter wbadmin enable backup to see the settings you have enabled.
    10. Type wbadmin get versions to see what backups have completed.

    Windows Backup Failure on Windows Server 2008

    Posted on Leave a commentPosted in 2008

    I recently had a case where Windows Backup would fail at approx. 75% complete during a full backup. The backup utility and command line both reported that “The system cannot find the file specified”. The Event Viewer/Application… Services/ Microsoft/ Windows/ Backup/ Operational reads “Backup target is running low on free space. Future backups to this target may fail for want of enough space.” and then at the same time and immediately after that we get “Backup started at ‘TimeZ’ failed with following error code ‘2147942402’” which means file not found or unknown error.

    After a series of email communications with the Windows Backup team at Microsoft India (where, incidentally, the program was developed) the answer came back that I should run chkdsk /r and reboot the server. As this process can take hours this occurred out of hours and actually in my case needed to be repeated twice. A normal chkdsk command, run whilst the server was online, reported that the disk had errors and could not continue.

    After running chkdsk /r twice, from an elevated command prompt, the backup started to work again.

    Remote Web Workplace in Essential Business Server 2008 Always Prompts for Password and Never Logs In

    Posted on Leave a commentPosted in 2008, ebs 2008, remote desktop, remote web workplace, sbs 2008, windows

    There is a published problem with EBS 2008 where Outlook prompts for a password all the time when connected over HTTP/RPC (Outlook Anywhere) – see the Microsoft EBS Team Blog. We have found that the same problem is also exposed in the Remote Web Workplace when trying to connect over Remote Desktop to your PC or to the servers.

    The problem is that the authentication for the Remote Desktop is broken because Outlook has failed to connect based on the published issue mentioned above. The failure of Outlooks authentication breaks the DefaultAppPool is IIS. Recycling the application pool fixes the issue – but only for a short while. It breaks again at the next failed Outlook login. And because the breaks in authentication are due to Outlook it is difficult to see why Remote Desktop ceases to operate.

    But apply the same fixes from the above blog and Remote Desktop begins to work and stays working.

    To fix, run the following four commands from an elevated command prompt on the messaging server:

    • %windir%\System32\inetsrv\appcmd.exe unlock config -section:system.webServer/security/authentication/windowsAuthentication
    • %windir%\System32\inetsrv\appcmd.exe set config “Default Web Site/ews” -section:windowsAuthentication -useKernelMode:False /commit:apphost
    • %windir%\System32\inetsrv\appcmd.exe set config “Default Web Site/AutoDiscover” -section:windowsAuthentication -useKernelMode:False /commit:apphost
    • %windir%\System32\inetsrv\appcmd.exe set config “Default Web Site/OAB” -section:windowsAuthentication -useKernelMode:False /commit:apphost

    The above commands are probably wrapped for reading on your screen – each bullet point is a single command to be entered as one line. Instructions for making changes via the GUI can be seen on the above blog post.

    SBS 2008 SharePoint Install Breaks Default SBS Web Site

    Posted on Leave a commentPosted in 2008, https, iis, remote web workplace, rww, sbs 2008, terminal server, ts gateway, windows

    A recent installation of a second SharePoint site on Small Business Server 2008 broke the Remote Web Workplace site for access from the internet. Intranet access to the site worked fine, but from the internet where the http request to the site is redirected to https had stopped working.

    Opening up IIS 7 Manager and checking the bindings of the SBS Web Applications site showed that the site had two http bindings and a https binding. The https binding was for * under IP Addresses and port 443. Clicking the Edit button on this binding showed that the certificate was not correct. This was the reason the site was not working, as a https site requires a certificate.

    So I selected the correct certificate and clicked OK. And got the following error:

    A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)

    The reason is that the installation of the SharePoint site, and the installation of the certificate to support that site broke the binding for the TS Gateway role on the Windows 2008 machine. The broken binding on the SBS Web Applications site was because of this broken TS Gateway configuration and to fix the above error in IIS required fixing the TS Gateway issue. Note that at no point in the configuration of the SharePoint application was the TS Gatway role configuration changed – the installation of another certificate on the server broke the TS Gatway which broke the Remote Web Workplace SBS Web Applications site.

    Opening Server Manager and navigating to the Roles/Terminal Services/TS Gateway/Servername area showed a message in the middle pane of the Server Manager saying that configuration of the TS Gateway was not complete. Clicking this link brought up the TS Gateway SSL Certificate page of the Properties dialog. Click Browse Certificates and select the correct certificate. In SBS 2008 this will be the Remote Web Workplace certificate. Click OK to close the dialog and you will now be able to check the https binding on the SBS Web Applications website. The error will now not occur, and the https binding will be bound to the correct certificate.

    If you are not running SBS 2008 then the above is possible, just it is more likely to be a problem with the Default Web Site bindinging instead.

    Additionally, I noticed after I had written the above that this error also occurs if you delete the certificate used by the TS Gateway from the IIS box and as well as breaking TS Gateway (which would be expected) it also breaks the “Add a trusted certificate” wizard in the SBS Server Console. The Add a trusted certificate wizard crashes when started with just a failed application message and nothing in the event log. To fix make sure the SBS Web Application IIS site is bound to a valid digital certificate.

    Hyper-V and VSS Backups Cause Bluescreen

    Posted on Leave a commentPosted in 2008, backup, server core

    I found the other week that my Hyper-V server, running Server Core and nothing else was restarting all of its own accord. As this is just a server at home, and the monitor is switched off 99% of the time I had not noticed it blue screening.

    So looking in the event log (remotely of course, as it was running Server Core) to see why, I noticed it had done the same thing every day at a few minutes past 1pm – one of my scheduled backup times during the day.

    I was getting Event ID 1001 at about 1:03pm each day. So I changed the time of the backup (using Windows Server Backup, command line) to 11pm and I got 1001 bugchecks at 11:03pm each day.

    There was nothing else recorded in the event log, apart from the usual system start/TCP-IP etc messages and no clue as to the reason for the failure. All I had was the BugCheck, an example being 0x0000007e (0xffffffffc0000047, 0xfffff80003676b48, 0xfffffa60019ff5c0, 0xfffffa60019ff660.

    A bit of research later, and ignoring most of the posts regards VSS and Hyper-V I came across http://support.microsoft.com/kb/958662/en-us and http://support.microsoft.com/kb/960038/en-us (the latter of these is a hotfix) which I applied and solved the problem.

    It would seem that Hyper-V and VSS based backups have an issue with some backups if a virtual machine is in a running state. It is possible to save the Hyper-V guest machine and then back it up without issue, but of course this kicks people of the virtual machine – a bit pointless really unless its a development machine. To turn off backup for a Hyper-V machine, so that the server does not bluescreen then either disable the Backup (volume snapshot) option in the guest machine settings, under Integration Services or install the hotfix and reboot once.