-->

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:

Get-CsExternalAccessPolicy

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

Allow_Federation_Public_Outside_Access

**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:

Get-CsConferencingPolicy

I need this one here:

ConferencingClient_No_Recording

**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:

Proxies
 
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,
                                         EUM:stacey.branham@exchangeitup.com;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:

OCSUmUtil

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

Loading

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:

OCSUmUtil AA


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.

Saturday, November 4, 2017

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

In Part 1 of this series I showed you how to allow the SFB servers and groups to authenticate with the Exchange servers over a Selective Trust.

In this post I'll show you how to create a certificate to use for Unified Messaging to allow SFB/UM integration.

Create A Certificate For UM

We'll need to create a certificate in Exchange in order for SFB/UM traffic to use TLS.

The main requirement is that the Exchange Server FQDN's need to be present on the cert.

**Note** If you have multiple Exchange servers, include each server name on a single cert.

We're going to use a Private CA (Certificate Authority) because this is internal only, so you don't need to spend money on a public cert.

Also, we won't be using our SAN cert since it's not good practice to use server FQDNs because it can cause problems.

Certificate Request

On an Exchange server, open the EAC and navigate to Servers > Certificates.

Click the + and leave the first option "create a request for a cert from a certificate authority" checked, and click Next

Request UM Cert 2

Name the cert something like Exchange UM, and click Next:

Request UM Cert 2

Just click Next, do not choose the wildcard option:

Request UM Cert 3

Click and select the Exchange server you're currently on, and click OK, then Next:

Request UM Cert 4

You don't need to touch anything here, just click Next:

Request UM Cert 5

Here, you will remove all entries except your namespace (eg. mail.exchangeitup.com) and add your Exchange servers.

Select each domain name and click - button, leaving your namespace.

Click the + and type in the FQDN of each Mailbox Server, then click Next:

Request UM Cert 6

Enter your company details and click Next:

Request UM Cert 7

Enter a UNC path to store the request file...it's easiest to use the exchange server you're on like \\mbx1.exchangeitup.com\c$\temp\cert\umcert.req:

Request UM Cert 8

Browse to the path where you saved the .req and submit that file to your Internal CA.

Fire up your browser and go to your Internal CA's enrollment webpage.

Click Request a certificate:

Request UM CA 1

Click submit an advanced cert request:

Request UM CA 2


Click submit a certificate request by using...blah blah...file:

Request UM CA 3

Open your umcert.req file in a text editor like Notepad and copy the whole block of text.

Then, paste it into the Saved Request form.

Change the cert type dropdown to Web Server.

And click Submit:

Request UM CA 4

When it's done, click the Download certificate:

Request UM CA 5

Save the .cer file on your Exchange server to somewhere like C:\Temp\Cert\ExchangeUM.cer

Complete Cert Request

Back in the EAC, you'll see your pending cert request:

Complete UM Cert Req 1

Select the request and click Complete in the right-pane:

Complete UM Cert Req 2

Provide the UNC of the .cer file and click OK:

Complete UM Cert Req 3
Once it's finished, you'll see the cert is installed and valid:

Complete UM Cert Req 4

Assign the UM Cert

Double-click your new UM cert to bring up the editor, and click services.

Put a check in the boxes for Microsoft Exchange Unified Messaging and Unified Messaging Call Router. Then click Save:

Assign UM Cert 1

If you are overwriting another cert that is assigned to those services, you will get a prompting asking to confirm. Click Yes.

Export/Import UM Cert To Other Exchange Servers

Select the UM cert and click the ..., then click Export exchange certificate:

Export UM Cert 1

Input a UNC path to save the .pfx file like \\mbx1.exchangeitup.com\C$\temp\cert\exchangeum.pfx and set a password click OK:

Export UM Cert 2

Click the ... again and select Import exchange certificate:

Import UM Cert 1

Enter your UNC path and password for the .pfx file:

Import UM Cert 2

Click the + and select all of your other Exchange servers and click OK, then Finish:

Import UM Cert 3
 
On each of your Exchange servers restart the UM Service and the UM Call Router Service by running the following cmdlets in the Exchange Management Shell (EMS):
 
Restart-Service MSExchangeUM
 
Restart-Service MSExchangeUMCR 
 
Export/Import UM Certificate on the SFB Server
 
On your Exchange server, browse where you stored the exchangeum.cer file (in our case C:\Temp\Cert\exchangeum.cer) and copy that file.
 
Now switch over to your SFB server and paste it somewhere like C:\Temp\Cert
 
Go to start and search for certlm.msc and open the certificate manager.
 
Navigate to Trusted Root Certification Authorities > Certificates
 
SFB Cert import 1
 
Right-click anywhere in the right-pane, select All Tasks > Import
 
Follow the wizard to import the Exchange UM cert:
 
SFB Cert import 2
 
SFB Cert import 3
 
SFB Cert import 4
 
SFB Cert import 5
 
 
 
Now we have allowed the Skype For Business server to authenticate with the Exchange forest, and set SFB to trust the Exchange UM certificate.
 
In the next post we will set up the actual UM integration.