Exchange 2010 Hybrids in 2018!

So it seems that Exchange 2010 hybrids are still alive and in demand even though the product is out of support and most certainly should have been replaced by now. However when customers are still running Exchange 2003 what can you do!

So as you can see by the title Exchange 2010 hybrids are still doing well out in the wild and customers who want to go through this transition have some challenges to say the least!

You might say why don’t I use 3rd party migration tools? Why are you doing a hybrid which is a valid point but lets not go there for now!

Well I wanted to highlight some of the technical challenges that Microsoft haven’t fully published out there for this product.

First of all as you are all aware the Hybrid Configuration Wizard is downloaded online so you can get the latest build/updates/etc (the same still applies to 2010). Generally most people would run this from their Exchange platform and this is where the HCW has some challenges although the HCW doesn’t have many hard pre reqs it won’t download unless .net 4.5.1 is installed on the server and furthermore won’t even start installing unless you have .net 4.6.2 of which neither are supported on Exchange 2010.

Now I am sure you are all aware but if not you can run the HCW from any server/workstation within your LAN as long as you have the .net requirements and you have defined the Powershell URL in your Exchange 2010 setup. If not you should publish this internally to allow the remote workstation to connect to Exchange and run the HCW! Ensure the firewall ports are open.

Then hopefully a few clicks later everything is in place and you are ready to go with your Exchange 2010 Hybrid to o365!

Advertisements

Office 365 Microsoft Phone System Call Queues

It has been a while since my last blog post I have been busy doing lots of deployments. So expect more post over the coming weeks.

This one will be a relativity quick one. Whilst working on a customer deployment for Microsoft Phone System fully in the cloud the customer wanted to setup some call queues and auto attendants which was great. All setup and away we go however on testing if anyone ever called the call queue all they just got was the music on hold and the people assigned to the queue never got the SfB notification.

So checking everything once , twice everything looked right but nope it still wasn’t working!

I sat back and looked at how the whole SfB was configured in the Cloud and noticed that the customer had closed their federation. So I added their own public domain to the allowed federation list and waited 15 minutes then BOOM it started working.

So point to note if anyone closes their federation ensure they add themselves as a federated domain in SfB Online!

Also another little nugget I found is the following site which allows users to manually opt out of a queue if they want to do so – https://mysettings.lync.com/pstncalling

Connect a Shared Mailbox from O365 to Outlook via IMAP

I recently was asked how to connect a shared mailbox via IMAP to an Outlook client now this isn’t standard behavior or common practice as only a licensed user should access a mailbox. Now I know there are many resources online and suggestions out there but I am aiming to clear this one up using an Outlook 2016 client which does work with Office 365!

First of all create a shared mailbox, in this instance we are using shared@adam-hand.com. Then give full permissions as you normally would for a licensed account in this instance adam@adam-hand.com.

  1. Open up the profile manager on Outlook
  2. Add a new profile, and give it a name
  3. Select “connect to a different account” in the bottom right hand corner
  4. Select “Manual setup or additional server types
  5. Select POP or IMAP
  6. Fill out the following information
    • Your Name – What ever you want
    • Email address – shared@adam-hand.com
    • Account Type – IMAP
    • Incoming mail server – outlook.office365.com
    • Outgoing mail server – smtp.office365.com
    • User name – adam@adam-hand.com\shared@adam-hand.com
    • Password – The password for adam@adam-hand.com
    • Tick the box for remember password
    • Select the more settings button
    • Under the Outgoing Server tab select “My outgoing server (SMTP) requires authentication” and “Use same settings as my incoming mail server”
    • Select the Advanced tab
    • Under incoming server IMAP enter – 993 and SSL/TLS
    • Under Outgoing server (SMTP) enter – 587 and STARTTLS
    • Select Ok
  7. Then Next and the test should pass successfully and you are good to go.

OWA Attachment Controls in Office 365

A customer recently asked for the following settings I want to block users from downloading attachments in OWA (Outlook on the Web) but allow them to edit documents in Office Online.

Simple enough scenario or so I thought!

Looking at the GUI the only option you have under file access is “Direct file access” which allows full control and downloading of documents. Turning this off blocks all file attachments from editing, downloading or saving to OneDrive for Business.

Ok so lets look under the hood in PowerShell or owamailboxpolicy the options available to us that we want to look at are as follows:

DirectFileAccessOnPublicComputersEnabled Specifies left-click and other options available for attachments when the user has signed in to Outlook Web App from a computer outside of a private or corporate network. If this parameter is set to $true,Open and other options are available. If it’s set to $false, the Open option is disabled.
DirectFileAccessOnPrivateComputersEnabled
ForceWacViewingFirstOnPublicComputers Specifies whether a user who signed in to Outlook Web App from a computer outside of a private or corporate network can open an Office file directly without first viewing it as a webpage.
ForceWacViewingFirstOnPrivateComputers
ForceWebReadyDocumentViewingFirstOn

PublicComputers*

Specifies whether a user who has signed in to Outlook Web App can open a document directly without first viewing it as a webpage.
ForceWebReadyDocumentViewingFirstOn

PrivateComputers*

WacViewingOnPublicComputersEnabled Specifies whether a user who has signed into Outlook Web App from a computer outside of the corporate network can view supported Office files using Outlook Web App.
WacViewingOnPrivateComputersEnabled
WebReadyDocumentViewingOnPublic

ComputersEnabled*

Specifies whether WebReady Document Viewing is enabled when the user has signed in from a computer outside of the corporate network.
WebReadyDocumentViewingOnPrivate

ComputersEnabled*

*Although this commands appears if you run a set-owamailboxpolicy you CANNOT update the settings

Now the first item I will point out is how does Office 365 know what is public or private. Well the short answer is it doesn’t! Everything is private.

Well how can it….Well with some further digging you need ADFS deployed and a claim rule as follows as this will identify the location of the users.

Below I will describe how to configure the controls as requested.

First of all in PowerShell you need to run set-organizationconfig -publiccomputersdetectionenabled $true

Then within ADFS you need to do the following (This is based on ADFS 2.0 once carried out on ADFS 3.0 I will update):

  1. On the Start Screen, type AD FS Management, and then press Enter.
  2. In AD FS console tree, under AD FS\Trust Relationships > Relying Party Trusts and select O365 Identity Platform.
  3. In O365 Identity Platform, click Edit Claim Rules > Add Rule > Issuance Transform Rules.
  4. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule from the list, and then click Next.
  5. On the Configure Rule page under Claim rule name type the display name for this rule.
  6. Under Custom rule, input the following:exists ([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) => issue(Type = "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value = "false");
  7. Next, input the following: NOT exists ([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) => issue(Type = "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value = "true");
  8. Click Finish.
  9. In the Edit Claim Rules dialog box, click OK to save the rule.

Then once you have set the above within your OWA Mailbox Policy set the following:

Set-OwaMailboxPolicy -identity MyOWAPolicy -DirectFileAccessOnPrivateComputersEnabled $false -ForceWacViewingFirstOnPrivateComputers $true -WacViewingOnPrivateComputersEnabled $true

Finally apply the policy to the user(s) this will apply to.

Now what the above configuration will do is stop users from downloading attachments and allow them to edit and view within a browser.

Now if you want to set the same policy’s externally as well you can follow the steps switching the commands for public to private and you must use ADFS.

Configure Lync/SfB with Office 365 for server to server authentication

Recently I was advised there were a lot of events being generated from a customers Lync server where they had recently migrated all their mailboxes to Office 365 but were using Enterprise Voice on premise. The event being generated was as follows:

Event ID – 32053 from the LS Storage Service – Storage Service had an EWS Autodiscovery failure.

I won’t past the whole error here but the crux of the error was as follows:

“ExchangeAutodiscoverException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=adam@domain.com, Autodiscover Uri=http://autodiscover.domain.com/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL> —> Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The request was aborted: The request was canceled. —> System.Net.WebException: The request was aborted: The request was canceled. —> “

Now looking into this the Lync server could not create the connection to Office 365. I could see Autodiscover is working and the server could get a logon prompt if they hit the URL.

So I decided to check the OAuth Configuration – get-csoauthconfiguration and could see the URL for Exchange Autodiscover was set correctly however the clientauthorizationoauthserveridentity was still pointing at the hybrid exchange management server. So it lead me onto how do you setup an OAuth trust between a cloud service and on premise servers?

Well luckily enough help is at hand and I will try to guide you through the process…

First of all you must connect to PowerShell for the MSOL service in O365 and run the following get command:

  1. get-cstenant and then grab the displayname of your Office 365 tenancy.
  2. Fire up a Lync/SfB On Premise PowerShell Management Session – and then run the following command –
    New-CsOAuthServer microsoft.sts -MetadataUrl "https://accounts.accesscontrol.windows.net/"Displayname"/metadata/json/1" where "Displayname" is the name you got from step one
  3. Then run Get-CsPartnerApplication “microsoft.exchange” – If you get a result then carry out step 4 if not move onto 5
  4. Remove-cspartnerapplication “Microsoft.Exchange”
  5. New-CsPartnerApplication -Identity microsoft.exchange -ApplicationIdentifier 00000002-0000-0ff1-ce00-000000000000 -ApplicationTrustLevel Full -UseOAuthServer

Once this is complete you have configured Lync/SfB to use the Office 365 OAuth servers and you will start to see the following errors in the Event Log

Event ID 32054 – LS Storage Service – Storage Service had an OAuth authentication failure. CreateAppActAsToken failed, ex=OAuthConfigException: code=ErrorOAuthSts, reason=Recv RST response, failed, sts=https://accounts.accesscontrol.windows.net/a26842db-0e87-4d85-b745-9b7bf0f96067/tokens/OAuth/2, resource=00000002-0000-0ff1-ce00-000000000000/autodiscover-s.outlook.com@domain.com, ex=The remote server returned an error: (401) 

This s fine at this stage as we haven’t created the trust between on premise and Office 365 yet.

  1. Connect to Office 365 MSOL PowerShell whilst importing the following module : import-module MSOnlineExtended
  2. Run get-MSOLServicePrincipal – This will return lots of results but you are specifically after the one with the displayname “Microsoft Lync Server”
  3. Now at this stage I have made an assumption and that is that the OAuth certificate used by the Lync/SfB server on premise is up to date and is available to be exported. If not renewal this!
  4. Open up the MMC for certificates and identify the exact certificate currently assigned to Oauth for Lync/SfB this is generally an internal certificate. Export it as a X.509 Base64 (Which is not the default)
  5. Then run the following PS script where the line certificate.import contains the location of the exported certificate:
  6. $certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
    $certificate.Import("C:\Certificates\Office365.cer")
    $binaryValue = $certificate.GetRawCertData()
    $credentialsValue = [System.Convert]::ToBase64String($binaryValue)
  7. New-MsolServicePrincipalCredential -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 -Type Asymmetric -Usage Verify -Value $credentialsValue -StartDate 02/12/2015 -EndDate 01/12/2015
  8. Now for the above command there are two items to be bear in mind first of all the startdate cannot be before today and the enddate can only be for a period of one year so even if the certificate lasts longer this setup can only last for a year!
  9. Get-MsolServicePrincipalCredential -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 - The Returnkeyvalue is "Asymmetric"
  10. Then you should get a result with your certificate with the dates specified.
  11. Finally you need to set the set-cssoauthconfiguration -exchangeautodiscoverurl from https to http as currently https will not pass the tests and also flag up errors. This is done from the on premise Lync/SfB Management shell

Then you should be able to run test-csexstorageconnectivity -verbose and get a test passed result!

You should also see an event with ID 32048 where it states “OAuth was properly configured for Storage Service.

CsOAuthConfiguration validly configured”

Finally when you need to renew your setup which will be every year you will need to remove the MSOLServicePrincipal and replace it with your new certificate using the above process!

 

Modern Authentication using Azure MFA across Exchange and Lync/SfB Hybrid Options

Updated – 25/01/2017 – This article still generates a lot of questions so I thought best to update and clarify some of the comments.

As part of the work I have been doing on Modern Authentication I thought I would share a table which is useful to understand how the Office clients authenticate in a mixed hybrid environment. Note: currently SfB Online is NOT supported by ADAL (modern authentication) but once it is this will be the model. It is also now supported with SfB On-Premises but ONLY with SfB 2015 running at least the March 2016 updates. However the environment needs to be a pure on premises and NOT hybrid as this is still not supported. It should also be noted that if Exchange is wholly in O365 then you must also reference the following article to allow the fat clients to work.

I would also like to point out this article for further reference by Trevor Miller – https://ucvnext.org/2016/02/office365-modern-authentication-skype4b-hybrid-exchange-hybrid/

As well as this one – https://technet.microsoft.com/en-gb/library/mt710548.aspx

Modern Authentication using MFA

Clients and Office 365 tenants enabled for OAuth/strong> Skype for Business on-premises Skype for Business Online (Office 365)
Exchange On-premises OAuth flows are supported against on-premises SfB 2015 only running March 2016 CU.

Which authentication method will Skype for Business use?

The client will use NTLM/Kerb/Nego to connect to both Exchange and Skype for Business servers.

What happens if MFA is enabled?

MFA challenges should be respected in this topology

What does this mean for the end user?

The MS statement is this currently still isn’t supported. – https://www.youtube.com/watch?v=O9JChbPhFZc&feature=youtu.be&t=47m37s

Which authentication method will Skype for Business use?

The client will use OAuth against Skype for Business Online tenant, and NTLM/Kerb/Nego against Exchange on premises.

 

 

What happens if MFA is enabled?

True MFA in Skype for Business (Azure MFA or Azure AD MFA)

What does this mean for the end user?

Currently I have no direction on what will happen with on premises Exchange but you would need to be running at least 2013.

Exchange Online (Office 365) Which authentication method will Skype for Business use?

The client will use NTLM/Kerb/Nego to connect to Skype for Business on-premises, and IDCRL to connect to Exchange Online.

What happens if MFA is enabled?

MFA challenges will not be respected in this topology.

What does this mean for the end user?

Modern Authentication will not work unless you run the regfix

RECOMMENDED

Which authentication method will Skype for Business use?

The client will use OAuth against both Exchange and Skype for Business Online tenants.

What happens if MFA is enabled?True MFA in Skype for Business (Azure MFA or Azure AD MFA)

 

What does this mean for the end user?

Modern Authentication will  work if you are running a pure SfB Online with no hybrid or spilt domain

The main items to bear in mind here is that when using Lync/SfB on premise generally because of Enterprise Voice currently MFA will NOT be respected by the client.

Legacy Authentication using App Passwords with Azure MFA

Legacy Auth (IDCRL, using App Passwords) Skype for Business on-premises Skype for Business Online (Office 365)
Exchange On-premises N/A

On-premises server products do not support app passwords.

Which authentication method will Skype for Business use?

The client will use IDCRL against Skype for Business Online tenant, and NTLM/Kerb/Nego against Exchange on premises.

What happens if App Passwords are enabled?

App Passwords prompts will show up in Skype for Business.

Prompting behavior

Users may see multiple prompts (for two different passwords) from Skype for Business client attempting to connect to Skype for Business server and Exchange.

Exchange Online (Office 365) Which authentication method will Skype for Business use?

The client will use NTLM/Kerb/Nego against Skype for Business on premises tenant, and IDCRL against Exchange on premises.

What happens if App Passwords is enabled?

App Passwords in Skype for Business for connectivity to Exchange. We recommend users log in with app passwords first and then use their domain credentials if needed.

Prompting behavior

Users may see multiple prompts (for two different passwords) from Skype for Business client attempting to connect to Skype for Business and Exchange.

RECOMMENDED

Which authentication method will Skype for Business use?

The client will use IDCRL against both Exchange and Skype for Business Online tenants.

What happens if App Passwords are enabled?

Users will have to use App Passwords instead of their domain passwords in Skype for Business.

 

Lync/SfB Unified Contact Store with Exchange

I came across some strange errors recently with a customer where the setup was as follows Lync/SfB on premise due to Enterprise Voice but had Exchange Online. Whereas the issues being seen were the OWA IM client wouldn’t sign in, on mobile devices the buddy list would not show at all and the mobile client would struggle to resolve names when you received an instant message. Upon further digging this was due to the Unified Contact Store that Lync 2013/SfB 2015 and Exchange 2013/16 use and share.

Now the following is the statement of support-ability from Microsoft referenced here: https://support.microsoft.com/en-gb/kb/2614614#bookmark-more

Supported Lync/SfB Scenarios

Lync and Exchange integration features Outlook integration (EWS, MAPI) Outlook Web App integration (IM/P) Outlook Web App online meetings (scheduling) Unified Contact Store High-resolution contact photos
Skype for Business Online only Supported Supported Supported Supported Supported
Lync Server 2013 only Supported Supported Supported Not supported Supported
Lync Server 2013 hybrid deployment with Skype for Business Online Supported Supported Supported Supported* Supported

*Supported only for Skype for Business Online users in the hybrid deployment.

Now from this you will notice that UCS is not supported when you have Lync/SfB on premise and Exchange Online. Now I should point out at this stage that the UCS store was introduced in Exchange 2013/16 so if you migrated or are running Exchange 2013/16 this will affect you.

To resolve this there are a couple of options available:

  1. Disable the UCS store before you migrate to Exchange Online – As this will back up the contacts and you will not lose your buddy list. (I will discuss the commands later on)
  2. Migrate the users back to on premise and then disable UCS and migrate the user back to Exchange Online
  3. Force disabling the buddy list which will wipe out the contacts from the Lync/SfB Client, however if you have not re pointed your Exchange records to O365 this may allow the back of contacts – However in my scenario I was unable to test.

The PowerShell commands available to this are as follows:

  1. To disable UCS for the user – Invoke-CsUcsRollback ahandyblog@test.com -force -verbose
  2. To create a global policy to disable UCS the following command is available:
    1. Set-CsUserServicesPolicy -Identity global -UcsAllowed $False
  3. To create a policy for individuals you can carry out the following:
    1. Create a policy – New-CsUserServicesPolicy -Identity “DisableUnifiedContactStore” -UcsAllowed $false
    2. Then assign the policy to a user – Grant-CsUserServicesPolicy -Identity “ahandyblog” -PolicyName “DisableUnifiedContactStore”
  4. Alternatively you can block globally and allow some users to still user UCS if there mailbox is on premise which is as follows:
    1. Create a policy – New-CsUserServicesPolicy -Identity “EnableUnifiedContactStore” -UcsAllowed $true
    2. Then assign the policy to a user – Grant-CsUserServicesPolicy -Identity “ahandyblog” -PolicyName “EnabledUnifiedContactStore”

Once you have carried out the commands the mobile client and OWA IM should start to work immediately.

Office 365 Modern Authentication using ADAL

I have spent the last few weeks testing and trying the various setups with Azure MFA when using modern authentication using Office 2016 ProPlus and thought I would share my experiences.

In general the process is pretty slick and seamless to the end user the main areas of concern is the lack of public information on the matter. There are various discussion articles which are all linked below. However it should be made clear that although Office 2013 and 2016 can support modern authentication Office 365 is NOT fully supported and is still currently in a public preview.

The workloads supported are SharePoint Online, the Office 365 tenant, Intune, Azure AD, Exchange Online (limited support – Also note ActiveSync will still require App Passwords if Azure MFA is enforced). Most mobile applications Outlook/OneDrive/Outlook Groups/RMS Sharing/Intune Company Portal do support MFA however I have found the Delve application currently doesn’t

Unsupported Workloads – Skype for Business Online – However the Skype for Business client does support Modern Authentication, however when using Lync/SfB On premise the client struggles to establish connection as authentication fails to Exchange Online to pull information. However if you want to use SfB Online then you can continue with App Passwords if this is a required workload.

https://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/

Although you can request via this page to turn on your tenant for Modern Authentication the PowerShell command is actually enabled for admins already which is:

set-organizationconfig -oauth2clientprofileEnabled $true to turn this off run the command again with $false

Now leaving this on does not affect client authentication if you are NOT enforcing Azure MFA this will only come into play when Azure MFA is turned on!

Now to the client Office 2013/16 supports modern authentication,  however when using 2013 you need to add the registry key that is detailed here – https://support.office.com/en-gb/article/Enable-Modern-Authentication-for-Office-2013-on-Windows-devices-7dc1c01a-090f-4971-9677-f1b192d6c910?ui=en-US&rs=en-GB&ad=GB for Office 2016 you do not need the registry key although if you do put it on the machine it won’t harm the client

To setup Azure MFA the following article discusses how to do this for the users – https://support.office.com/en-US/article/Set-up-multi-factor-authentication-for-Office-365-8f0454b2-f51a-4d9c-bcde-2c48e41621c6

The last item to bear in mind is ADFS Client Access policies you must be running at least ADFS 3.0 however not all policies are supported as discussed here – http://social.technet.microsoft.com/wiki/contents/articles/30253.office-2013-and-office-365-proplus-modern-authentication-and-client-access-filtering-policies-things-to-know-before-onboarding.aspx and you should also ensure you have configured ADFS with the additional rule as discussed here – https://azure.microsoft.com/en-gb/documentation/articles/multi-factor-authentication-get-started-adfs-cloud/

Now the main rule that doesn’t work is “Block all External Access to O365 expect Browser Based apps”, currently this also doesn’t work and if you want to block client access you will need to do this via conditional access policies in Intune or Azure AD – https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access-on-premises-setup/?rnd=1 However it should be noted you need to be running your schema level to at least 2012 R2 within your forest and their are a multitude of gotchas described in the article.

So overall this should hopefully give you some further food for thought and clarity on Modern Authentication using Azure MFA!

ATA – Microsoft Advanced Threat Analytics – Deployment Guide Part 3

In my previous posts we discussed the per-requisites and the installation of ATA in this post we will discuss the configuration.

Logon to your console http://ata.yourdomain.com/configuration navigate to ATA Gateways.

You should then see the gateway recently installed. You will then have a section for port mirrored domain controllers of which you will need to add one at a time all the DC’s that make up the organization. Then select the 2nd NIC which should be your port mirrored NIC to capture the traffic.

Once the initial sync has run which depending on the network can be quite quick you can then go and configure some further settings under the detection tab.

detection

Explanations of these settings are below:

  • Short-term lease subnets are subnets in which the IP address assignment changes very rapidly – within seconds or minutes. For example, IP addresses used for your VPNs and Wi-Fi IP addresses. They must be entered with the slash notation format eg 10.10.10.0/24
  • Honeytokens are honeypots that are not computer systems. Their value lies not in their use, but in their abuse. As such, they are a generalization of such ideas as the honeypot and the canary values often used in stack protection schemes. Honeytokens can exist in almost any form, from a dead, fake account to a database entry that would only be selected by malicious queries, making the concept ideally suited to ensuring data integrity—any use of them is inherently suspicious if not necessarily malicious. In general, they don’t necessarily prevent any tampering with the data, but instead give the administrator a further measure of confidence in the data integrity.
  • The last two areas DNS Reconnaissance and Pass-The-Ticket exclusions are for IP’s that you want to exclude from ATA monitoring which may flag up any issues.

Click save and wait for the settings to replicate.

Next if you want ATA to send out mail alerts go to the Alerts tab and config the settings as required. ATA also fully works with Office 365 as long as you have a licensed account.

Finally you may want to ensure the product is licensed pop down to licensing and enter your product key.

Then wait for 30 days for ATA to get a good over view of your environment and look out for alerts! Now just to be clear this doesn’t mean ATA will wait 30 days before it finds anything suspicious it will alert instantly if anything is discovered.

ATA – Microsoft Advanced Threat Analytics – Deployment Guide Part 2

In my previous blog post I discussed the requirements for ATA in this post I will discuss how to install ATA.

First of all we must start with the ATA Center before we install the collectors the wizard is quite straight forward and will get you to the configuration page very quickly as shown below:

ata config

For most parts you can accept the default settings. For the certificates you have two options which are:

  • Self Signed certificate – If so tick the box and away you go
  • Internal certificate from a CA – Now this can be changed later to a public certificate or a certificate with multiple SANS. But by default the wizard will only create the certificate with a single name which is the servers hostname by default.

Click install and the installation should complete. Then click Launch to launch the console you will notice certificate errors as by default ATA uses the console IP address to create the shortcut on the desktop.

At this stage if you want to change the certificate this is the best time to do so.

Create your certificate with the additional names required (it must contain the server name as one of them) the SAN could be something like ATA.yourdomain.com (also ensure you create an internal DNS A record that will resolve to the correct IP address).

Insert the certificate into the store locally on the server, then in bindings on IIS to change the certificate to your new one. Note that if the certificate does NOT have its private key IIS will throw up and error so ensure this is imported at the same time.

Restart IIS fire up the console with your name e.g. ata.yourdomain.com/configuration and you should be able to log in with your admin account without any warnings.

If you wish at this stage to create extra admins these can either be members of the local administrators group or the Microsoft Advanced Threat Analytics Administrators Group. Now because these are local groups you might want to create an AD group and nest this within the ATA Admins group to make it easier to manage.

mata console

If you have any problems getting to the console first of all ensure the service is up and running or consult the error logs at %programfiles%\Microsoft Advanced Threat Analytics\Center\Logs\Microsoft.Tri.Center-Errors.log

The next step is to configure and install the collector(s) or the ATA Gateway role. Once logged into the console navigate to Configuration and enter your service account that you created in the readiness steps as shown below. Then click Save

sA account mata

Now we need to download the ATA gateway setup from the console, but first of all logon to the server that will be the Gateway server and open up the ATA console. Navigate to Configuration again and click “Download ATA Gateway Setup”

Before you extract the files and run the installer ensure you have the following hotfix installed KB2919355 which you can check via PowerShell whilst running the following command:

get-hotfix -id kb2919355

Run the wizard until you get to the following page:

gateway

Select your installation path, as before you have two options for the certificate self signed or from an internal CA. Then the username and password of the service account we created in Part 1

This completes the installation. In the next part we will discuss the configuration of ATA in part 3.