Saturday, February 10, 2018

Exchange Enabling Mailbox Auditing Scheduled Task - Part 3

In my previous post, I showed that mailbox auditing takes up very little storage space. In this post, I'll show you how to create a Scheduled Task to enable auditing on newly created mailboxes...we don't wanna do that manually every time we enable mailbox, right?

Create a Service Account:

First, you'll want to create a Service Account in your domain, which will be used to run the scheduled task. It's best practice to use service accounts rather than your own account to run scheduled tasks, so if you ever leave your position and they deactivate your account, it won't break the task!

In your domain, create a new user called something like exchscriptaccount and set a super-strong password.

This account will need to be a member of the Records Management Role Group, otherwise it won't have permissions to enable auditing on mailboxes.

Next, add the newly created user to the Local Administrators Group on your Exchange Management Tools server or Exchange server if your running it from there. The scheduled task will need local admin rights to run PowerShell things, and since you have a super strong password, it's not an issue.

Creating The Task:

On your Exchange Management Server or an Exchange Server, open the Task Scheduler Control Panel, click Action > Create Task...

On the General tab:

Give it a name like Set Shared Mailbox Auditing

Click "Change User or Group..." hit "Locations" and switch to your domain, then search for your exchscriptaccount service account.

Check the box for "Run with highest privileges"

On the Triggers Tab:

Click "New..."

Set it for how often you need it to run. I run mine Daily at 12AM - no specific reason, but you do want it to run Daily.

On the Actions Tab:

Set the "Action" dropdown to "Start a program"

Under Program/Script, copy/paste the following:


In the "Add arguments" field, copy/paste the following:

-NonInteractive -WindowStyle Hidden -command ". 'C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | ? {$_.AuditEnabled -eq $False} | Set-Mailbox -AuditEnabled $True -AuditOwner SoftDelete, HardDelete"

**Note** You can create one Schedule Task to enable auditing on all mailboxes, or create separate tasks by specifying the Mailbox Type like I have above...it depends on your mailbox creation rate.
To set for mailbox type just change the "-RecipientTypeDetails SharedMailbox" to another mailbox type like "-RecipientTypeDetails UserMailbox"

In the Settings Tab:

Checkmark the following boxes:

- Allow task to be run on demand

- Stop the task if it runs longer than: 1 hour (if it runs longer than an hour, you got something wrong!)

- If the running task does not end when requested, force it to stop

Click OK when you have everything set.

Testing the Task:

In the main task window, right-click your new "Set Shared Mailbox Auditing" task, and click Run.

When it finishes running, you should have a (0x1) Last Run Result.

Check Our Work:

Check that auditing is set on All Shared Mailboxes by running:

Get-Mailbox -Filter {AuditEnabled -eq $false -and recipienttypedetails -eq "sharedmailbox"}

The output should be empty.

Now run:

Get-Mailbox -Filter {AuditEnabled -eq $true -and recipienttypedetails -eq "sharedmailbox"}

The list should show all Shared Mailboxes

Now, Exchange will do the boring job of applying auditing for you :)

Exchange Enabling Mailbox Auditing Storage Consumption - Part 2

In my previous post I showed you how enable mailbox auditing by mailbox type. Some Exchange admins are wary of enabling auditing for all mailboxes because of storage space concerns. But, the good news is: even on a huge mailbox with lots of activity, the space consumed is miniscule.

From my experience, Mailbox Auditing adds less than 1% of mailbox size. Which means it's totally safe to enable it on all mailboxes in your organization. Plus, disks are cheap...just add more!

The following mailbox is 91GB (why she has a mailbox that gargantuan I don't know. At that point, I bet she can't even find what she's looking for).

As you can see, the Audits folder size is very little, and I have the "-AuditOwner SoftDelete, HardDelete" options set on her mailbox.

Get-Mailbox "Christiane G" | Get-MailboxFolderStatistics -FolderScope RecoveraleItems | fl name,foldersize

Name       : Recoverable Items
FolderSize : 0 B (0 bytes)

Name       : Audits
FolderSize : 143.94 KB (44,994 bytes)

Name       : Calendar Logging
FolderSize : 3.678 MB (3,856,561 bytes)

Name       : Deletions
FolderSize : 273.4 MB (286,645,304 bytes)

Name       : Purges
FolderSize : 0 B (0 bytes)

Name       : Versions
FolderSize : 0 B (0 bytes)

**Note** If you don't see an Audits folder right away, it just means that the owner/admin/delegate hasn't done anything according to your -AuditOwner/Admin/Delegate settings in the mailbox yet. Give it time and once some modification happens, it will create that folder

So, auditing won't kill your Database storage, go ahead an enable it and make your life easier!

In the next post, I'll show you how to create a scheduled task to automatically enable auditing on newly created mailboxes.

Exchange Enabling Mailbox Auditing By Mailbox Type - Part 1

I enable mailbox auditing on all mailboxes in every Exchange environment I work on. Why? Because WHO MOVED MY CHEESE?!.
Actually it makes the exchange admin's life so much easier when dealing with users who come crying that "all my emails are gone!" Another reason, is 90% of the time the messages can be found in Recover Deleted Items, and my personal policy is to never restore Single Items from a backup; you deleted it...tough luck :)

In this 3 part series, I'll show you how to enable Mailbox Auditing by mailbox type; how much storage auditing actually consumes; and how to create a scheduled task to automagically set auditing when new mailboxes are created.

To enable auditing by mailbox type run the one or all of the following cmdlets:

User Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

Linked Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "LinkedMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

Shared Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "SharedMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

Room Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "RoomMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

Equipment Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "EquipmentMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

**Note** We only specifically set the -AuditOwner options, because the following settings for AuditAdmin and AuditDelegate are already set by default:
Create, Folder Access, Hard/Soft Delete, Move/Move to Deleted, Send on Behalf, and Update

The auditing options can be found here so you can see what you want to set.

To enable auditing on all mailboxes in the environment, run:

Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuditEnabled $true

**Note** This cmdlet will take quite a while depending on how many mailboxes you have. Which is why I usually use the cmdlets above to apply by mailbox type.

Now, you have auditing enabled on all mailboxes or the types you want. In the next post I'll show examples of the storage used by auditing...teaser: it's not as much as you think ;)

Sunday, January 21, 2018

Skype For Business Convert CsUser to CSMeetingRoom

In a previous post, I went over converting a Room Mailbox to a Linked Mailbox. During the Linked Room account conversion in the Exchange Resource Forest, we had already set up the Skype For Business account as a regular CsUser account in our Accounts Forest. I needed that CsUser account to be a SFB Meeting Room account.

**Note** While a standard SFB user account can be used for a meeting room, an actual Meeting Room account will give you more control over the conferencing device. From my experience, it also affects the presence of the contact...a standard user will show "offline" unless in a meeting.

So, I needed a quick way to convert that CsUser to a CsMeetingRoom without having to delete and re-create the account.

Luckily PowerShell makes it easy!

On your SFB server, fire up the SFB Management Shell and run the following:

Get-CsUser "bld 51 conference room b" | Enable-CsMeetingRoom -SipAddress "sip:confrmb@exchangeitup.com" -RegistrarPool pool1.exchitup.com

**Note** Change "bld 51 conference room b", "sip:confrmb@exchangeitup.com", and pool1.exchitup.com to match your environment.

To check that it works, run:

Get-CsMeetingRoom | fl name,sipaddress,registrarpool

And you'll get the following:

Name                    : Bld 51 Conference Room B
SipAddress           : sip:confrmb@exchangeitup.com
RegistrarPool       : pool1.exchitup.com

You'll also note that the user can no longer be seen in the SFB Control Panel, because Meeting Rooms can only be managed with the SFB Shell.

Now the presence should work correctly and you can book that room and have it join your conferences!

Saturday, January 20, 2018

Exchange Convert Room Mailbox to Linked Mailbox

I'm in the process of setting up Skype For Business Meeting Rooms and the issue is: my Exchange 2016 environment is installed in a Resource Forest, and SFB is located in the Accounts Forest.

This means we need Linked Mailboxes for the Rooms in order for the conferencing devices to login to SFB.

I already have tons of Room Mailboxes created in Exchange, and I really didn't want to delete and re-create those. So, I needed to be able to convert them to Linked Room Mailboxes.

According to MS TechNet, you have to disconnect the mailbox, and then create a linked account and connect the mailbox. That isn't required; you can convert directly with the following steps.

Create an AD account in the Accounts Forest.

Next, enable the new AD account as a SFB Meeting Room

Fire up the SFB Management Shell and run:

Enable-CsMeetingRoom -Identity "Bld51ConferenceRoomB" -SipAddress "sip:Bld51ConferenceRoomB@exchangeitup.com" -RegistrarPool "pool1.exchitup.com"

**Note** Change the Identity, SipAddress, and Pool to match your environment

DirSync the new account to the Resource Forest with MIM or whatever sync app you use - or you can copy all proxy addresses (SIP and SMTP) over manually

In the Resource forest, fire up the EMS (Exchange Management Shell) and run:

$cred = Get-Credential

Enter your Accounts forest admin creds

Next, run:

Set-User "Bld51ConferenceRoomB" -LinkedMasterAccount "exchitup.com\Bld51ConferenceRoomB" -LinkedDomainController dc1.exchitup.com -LinkedCredential $cred

**Note** Again, change the values to match your environment

To check that it worked, run:

Get-Mailbox "Bld 51 Conference Room B" | fl name,alias,recipienttypedetails

You'll get the following output:

Name                               : Bld51ConferenceRoomB
Alias                                : Bld51ConferenceRoomB
RecipientTypeDetails      : LinkedRoomMailbox

Or check the EAC:

EAC - Linked Room Mailbox

You'll see that you now have a "Linked Room" mailbox. Now users can schedule that conference room for more boring meetings ;)

Sunday, January 7, 2018

SFB Bulk Set External Access Policy To Users With Specific Conferencing Policy

My Skype For Business environment is shared by our US and Europe divisions of the company, which means we have many different policies for each side. This also means, I need to set policies on clients based on Organizational Unit (OU) and sometimes by client policies themselves.

For instance, our US side has stricter regulations because of the type of business we do, so our Conferencing Polices don't allow as many options as the EU side.
But, for those users who are enabled for conferencing, I needed to allow them to connect uninhibited from and to the outside world.

So, I came up with a PowerShell cmdlet to grab all users in a specific OU, with a specific Conferencing Policy assigned, and set a External Access Policy on them, all in one shot.

First, we'll need see what External Access Policies we have, so we'll run:


Depending on how many you have, scroll down the list; I'm looking for this one:


**Note** Yours will be named differently, but I want the one which we created that allows public access, federation, and external access.

Now, we'll find the Conferencing Policies, by running:


I need this one here:


**Note** Again, yours will be named differently, but I want the policy that allows conferencing, but has recording turned off.

Now, we can get a list of all users in an OU, with the above Conferencing Policy, and we'll output that to a TXT file...just to make sure it grabs the correct users:

(Get-CsUser -Filter {ConferencingPolicy -eq "ConferencingClient_No_Recording"} -OU "OU=US,DC=users,DC=com") | select name, conferencingpolicy, ExternalAccessPolicy | out-file C:\Temp\confclient.txt

We have our list and checked it twice...

Now, we'll Grant the External Access Policy from our first cmdlet, on those users in our list:

(Get-CsUser -Filter {ConferencingPolicy -eq "ConferencingClient_No_Recording"} -OU "OU=US,DC=users,DC=com") | Grant-CsExternalAccessPolicy -PolicyName "Allow_Federation_Public_Outside_Access"

Give it a bit for replication (depending on the size of your environment it can take a bit) and we'll check our list again, by running:

(Get-CsUser -Filter {ConferencingPolicy -eq "ConferencingClient_No_Recording"} -OU "OU=US,DC=users,DC=com") | select name, conferencingpolicy, ExternalAccessPolicy | out-file C:\Temp\confclient_extaccess.txt

**Note** I've changed the TXT file name, in case we want to cross-reference with our original list.

This new list should now show that all those users in the US Organizational Unit who have the "ConferencingClient_No_Recording policy assigned", now have the "Allow_Federation_Public_Outside_Access" policy assigned as well.

Now, those users can schedule outside meetings and make those sales or whatever they need to do!

Saturday, January 6, 2018

Exchange Force Using The GAL In Outlook Cache Mode

My Exchange environment consists of two Resource Forests (one in the US and one in Europe) with one Accounts Forest that syncs MailContacts with MIM.
User accounts are created and edited by our ServiceNow application, which often changes primary SMTP addresses making the OAB (Offline Address Book) out of date quite often.

Outlook clients in cache mode don't download the OAB regularly (it's every 24 hours or so) which causes NDRs a lot when sending cross-forest because Outlook can't resolve the contact. Microsoft should fix this BTW!

There's three ways to fix this:

You can run Outlook in online mode, like I do because my mailbox is tiny (email is not a data repository!) but some users have giant mailboxes so that might not be practical.

Or, you can have users empty their Outlook autocomplete cache often - not practical at all, but a quick fix.

Or, we can force Outlook to use the online GAL, instead of downloading the OAB.

**Note** This can put extra strain on the network, but I've personally never seen any adverse affects since the GAL isn't all that big, and who still runs slow networks these days?

**Note** If Outlook clients were to ever run in Offline mode (like on an airplane), they will not be able to resolve contacts; so those traveling salespeople should still use the OAB

Follow these steps to force the GAL:

1. Close all open Outlook windows (and the SFB/Lync client if it's running)

2. Download "HKCU-Policies-OAB-0.reg" from my Google Drive

- This will create and set the DownloadOAB reg key in CurrentUsers/Policies to "0" which is disabled

3. Double-click the "HKCU-Policies-OAB-0.reg" file, click yes to import. Click OK.

4. Download "HKCU-Software-OAB-0.reg"  from my Google Drive

- This will create and set the DownloadOAB reg key in CurrentUsers/Software to "0" which is disabled

5. Double-click the "HKCU-Software-OAB-0.reg" file, click yes to import. Click OK.

6. Download "deletoab.bat" file from my Google Drive

7. Right-click, run the "deletoab.bat" file as admin

- This will delete the OAB directory and files in the user's Appdata\Outlook folder.

8. Navigate to the following folder: %localAppData%\microsoft\outlook and verify that "Offline Address Books" is gone.
9. Open Outlook, make sure Offline mode is not on and search for a name to see that it works.

If you have a lot of clients that need this change, you can set it up as a GPO to push it out - I'll write a post on how to do that at a later date.

Sunday, December 17, 2017

Exchange/AD Get Mail Encryption Certs Assigned to Users

This is just a quick post; mostly for my own records. My boss asks me to find user certificates all the time, and after googling around I remember that "hey, I already know how to do this!" But just in case you need to find this info as well, here ya go!

We recently changed our RootCA which provides our certs for encrypting messages in Exchange, and found that some users were getting prompts in Outlook saying it couldn't open messages because the digital ID couldn't be found.

In order to see which users were still assigned an old cert, I came up with the following cmdlets that will spit out a CSV with the user (subject) and issuer (which CA).

You'll need to run this in the AD PowerShell, or from the Exchange Management Shell (which loads AD modules automatigically).

First, load the variable:

$users = Get-ADUser -Filter * -SearchBase "OU=users,DC=domain,DC=com" -Properties "certificates"

**Note** Change "OU=users,DC=domain,DC=com" to the OU you want to search through. If you want to grab the whole domain, use "DC=domain,DC=com" and change domain to your domain name.

Next, run:

$users.certificates | select subject,issuer | Export-Csv C:\Temp\Certs.csv

**Note** Change "C:\Temp\Certs.csv" to wherever you want to save the CSV.

Now, give that CSV to whoever pushes out certs, and tell fix it :)

Saturday, December 16, 2017

Exchange Disable OWA Externally With Kemp

{rant} In my organization, we have some "project managers" who have very little understanding of Exchange and therefore come up with policies that don't make any sense at all, like disabling OWA externally. To make matters worse, they're not even project managers for my US Exchange environment; they're located in the European HQ, which has it's own Exchange forest.
Even after presenting whitepapers and articles showing that OWA has a very small attack surface, and the Exchange servers aren't directly behind OWA (the reverse proxy is) they still want it disabled...stupid {end-rant}

I've seen this question tons of times on forums and some of the answers go to extreme lengths like:

- Setting up separate virtual directories in Exchange with new IPs and DNS (that's way too much work)
- Setting firewall rules to block IPs (this is a bad idea, especially if you federate with another organization, as it will almost certainly break your free/busy sharing)

If you run a Kemp LoadMaster (or any load balancer for that matter) the solution is pretty simple:

Disable the OWA SubVS on the External Arm.

On your LoadMaster, navigate to:

Virtual Services > View/Modify Services > Your External Arm

Click the Modify Button in the right-pane:

Kemp VIPs

Scroll down and expand SubVSs.

On the OWA row, click the Disable button under the Operation column on the right:

Kemp Disable OWA

It will show Disabled under Status

Now browse externally to your OWA site and you'll get:

OWA Not Found

**Note** This will also disable external EAC access. So tell your IT security trolls (who came up with the not-so-brilliant idea to disable everything) that if an emergency occurs, you'll have go to your computer, connect to the VPN, log into the EAC, and fix what broke...there will be no more instant support.

On the positive side, free/busy, federation, ActiveSync, and Outlook Anywhere will still function properly.

Saturday, December 9, 2017

Exchange Forward Meeting External Error: 0x80070075

In my environment, we have two Exchange Resource Forests (us.exchangeitup.com and eu.exchangeitup.com) both of which share an Accounts Forest (exchitup.com).

A few of my US users experience Outlook NDRs when forwarding meetings Cross-Forest - from US to EU.

The error thrown is this:

Subject: FW: Meeting
Sent: 12/5/2015 5:50PM

The following recipient(s) cannot be reached:

External User on 12/5/2017 5:50 PM
This message could not be sent. Try sending the message again later, or contact your network administrator. The client operation failed.
Error is [0x80070075-0x80070075-0x00501]

The error is directly from Outlook itself, not Exchange. If you run Message Tracking, you will see that the message was actually sent externally.

The problem I found is, the targetaddress (external forwarding address) does not match any of the external user's proxyaddresses.

**Note** All other forwarding to external mail systems worked fine.

We have an automated provisioning script that creates MailUser accounts in each Resource Forest and then MIM does a DirSync to populate the attributes.

On a few contacts, the primary SMTP address changed (they got married or something), but the targetaddress didn't update. So there was no address in the proxyaddresses that matched the target.

See this example:

Get-Recipient ExternalUser | fl *address*

EmailAddresses                 : {SMTP:external.user@eu.exchangeitup.com}
ExternalEmailAddress       : SMTP:external2.user@eu.exchangeitup.com
PrimarySmtpAddress         : external.user@eu.exchangeitup.com

So, while Exchange does send the message, Outlook can't find a suitable email address in the GAL/OAB for external2.user and throws the error.

To fix this, I added a proxyaddress matching the target:

Get-Recipient ExternalUser | fl *address*

EmailAddresses             : {SMTP:external.user@ue.exchangeitup.com;smtp:external2.user@eu.exchangeitup.com}
ExternalEmailAddress       : SMTP:external2.user@eu.exchangeitup.com
PrimarySmtpAddress         : external.user@eu.exchangeitup.com

Now, no more NDR's!

**Note** The above may not apply to your environment, it's just the solution I found. I have seen this error floating around on the forums that have different scenarios/solutions like emptying the Outlook autocomplete cache, changing to online mode, etc. Those did not work for me

Sunday, November 5, 2017

Exchange/SFB UM Cross Forest with Selective Trust - Part 3

In Part 2 of this series, I showed you how set up our UM Certificate so SFB will trust Exchange.

This post will walk you through setting up the UM Dial Plans, UM Mailbox Policies, and Auto-Attendants in Exchange and SFB.

**Note** Further down you will see two domain names, exchangeitup.com (which is the Exchange Forest) and exchitup.com (which is the SFB Forest).

**Note** You do not need to set up a Partner Application between Exchange SFB for UM Integration.
In my environment, SFB was already set as a Partner with our Europe Exchange Forest and there can only be one because it uses the autodiscover settings for that Exchange forest.
This threw me for a loop for while trying to figure out how to add my Exchange, but after trying different ways, I finally found UM Integration works without it :)

Create Unified Messaging Dial Plan

On an Exchange server, fire up the Exchange Management Shell (EMS) and run the following cmdlet:

New-UMDialPlan -Name "Headquarters" -VoIPSecurity "Secured" -NumberOfDigitsInExtension 4 -URIType "SipName" -CountryOrRegionCode 1

**Note** Change "Headquarters" to whatever you want to call the Dial Plan...its best to be location specific if you have multiple sites.

**Note** We're using 4 digit extensions, but you can set it to your needs. If you currently run 3 digit, then set  -NumberOfDigitsInExtension 3

Next, run the following cmdlet:

Set-UMDialPlan "Headquarters" -ConfiguredInCountryOrRegionGroups "Anywhere,*,*,*" -AllowedInCountryOrRegionGroups "Anywhere"

Just to make sure the settings take, I always restart the UM Services...it won't cause any harm to do in production hours because you're not using it yet ;)

Restart-Service MSExchangeUM
Restart-Service MSExchangeUMCR

Configure the Dial Plan

Creating a dial plan automagically creates a UM Mailbox Policy, with the naming convention using the Dial Plan name e.g. Headquarters Default Policy.

We need to modify that new policy with the following cmdlet:

Get-UMMailboxPolicy | Set-UMMailboxPolicy -AllowedInCountryOrRegionGroups "Anywhere" -MinPINLength "6" -AllowCommonPatterns $true

Since we only have one UM Mailbox Policy, we don't need to specify the name in the above command.

**Note** You can change the -MinPINLength to something lower than 6 but you'll want it secure.

Configure Auto-Attendants

**Note** We're not going to set up a Subscriber Access, because to be honest, who even uses those any more? I haven't in years, because users check their voicemail directly from Outlook or their phone.

In the EAC, go to Unified Messaging > UM Dial Plans

EAC UM Dial Plan

Select your Headquarters dial plan and hit the Edit (Pencil) button, or double-click the dial plan.

Scroll down to the Auto-Attendant section, and hit the +

UM Auto-Attendant

Enter a name like Headquarters-AA
***Do not include spaces in the name, Exchange will problems with that***.

Check both boxes for "create this auto attendant as enabled" and "set the auto attendant to respond to voice commands".

And enter an access number and hit the + to add it.

Then, click Save:

UM Auto-Attendant Config

**Note** The access number can be internal like 555-555-1234, or if you need external parties to be able to call it, you will need associate one of your DID's provided by your SIP Trunk provider.

Enable Users for Unified Messaging

Using the EMS, run the following cmdlet:

Enable-UMMailbox -Extensions 1234 -SIPResourceIdentifier "stacey@exchangeitup.com" -Identity "exchitup\stacey" -UMMailboxPolicy "Headquarters Default Policy"

**Note** Enter a unique -Extension or else Exchange will tell you it's already in use. Also, we didn't set a PIN, as we'll let Exchange randomly assign that.

**Note** -SIPResourceIdentifier stacey@exchangeitup.com is the Exchange forest; -Identity "exchitup\Stacey" is the Accounts/SFB Forest

Sync the EUM Proxy Addresses

In order for SFB to pick up the UM settings, a couple proxy address need to be copied over from the Exchange Forest to the SFB Forest.

The SIP Address also needs to be synced from the Accounts Forest to Resource Forest (but that should be done already, else there would be no integration at all between SFB/Exchange)

**Note** To automate this, it should be done with MIM or whatever DirSync tool you use

To manually set it, open Active Directory Users and Computers in the Exchange Resource Forest.

Navigate to the OU where your user resides and open the Properties.

Click the Attribute Editor Tab and scroll down to proxyAddresses and double-click it.

Copy both addresses beginning with eum and EUM:

Or you can use the EMS by running the cmdlet below and copy both EUM/eum lines:
Get-Recipient "stacey branham" | fl *email*

EmailAddresses            : {eum:1538;phone-context=Headquarters.exchangeitup.com,

Now switch to your SFB Forest and navigate to the OU of your user.

Follow the above steps and paste in the two eum/EUM addresses in the proxyAddress field.

This will result in:

Get-ADUser staceybranham -Properties proxyaddresses

proxyaddresses    : {eum:1538;phone-context=headquarters.exchangeitup.com,                                   EUM:stacey.branham@exchangeitup.com;phone-context=Headquarters-exchitup.com

Configure UM IP Gateway

In the EMS, run the following:

cd $exscripts

.\ExchUCUtil.ps1 -forest "yourSFBForestname.com"

**Note** You must include the -forest switch for Exchange to see SFB in another forest.

**Note** You will need to give it about 10-15 minutes after creating the dial plans before running the above script, or else the output will come up empty. You can however run the script as many times as you want.

At the end of the output you should see:

Poolfqdn                             UMIPGateway                                  DialPlans
-----------                             ------------------                                  ------------
sfb.exchitup.com                sfb.exchitup.com                              Headquarters

Now go to the EAC, and navigate to Unified Messaging > UM IP Gateways and you'll see your SFB frontend server listed:

EAC UM IP Gateways

Create Auto-Attendant Contacts

On your SFB server, navigate to C:\Program Files\Common Files\Skype for Business Server 2015\Support

Run the OCSUmUtil.exe as administrator and click Load Data:


This will take quite a while depending on your replication speed...


In the Exchange UM Dial Plan Forest, drop-down to your Exchange Resource Forest

Click the Add button:

Click Add OCSUmUtil

In the next window, select the Organizational Unit where you want the contact created.

Give it a name like Headquarters-AA

Assign a SIP Address like sip:Headquarters-AA (remove the trailing domain name in the address field. It should only be sip:Headquarters-AA

Set your desired server or pool if you have more than one.

Select "use this pilot number from Exchange UM" and enter the number you set for the AA in Exchange.

Select Auto-Attendant and enter the Headquarters-AA name.

And click OK:


Your AA contact will be created in the OU that you specified, and it will be listed in the OCSUmUtil:

OCSUmUtil Done

Now test it out!

In your SFB client and search for the AA contact like Headquarters-AA, and perform a Skype Call.

It should say something like "thank you for calling the Exchange auto-attendant..."

You can also direct dial the 504-555-1111 number.

Now test your voicemail, by calling the number you assigned to your user account and let it go to voicemail. It should send you over to the UM prompt to leave a message.