Showing posts with label Mailbox Server. Show all posts
Showing posts with label Mailbox Server. Show all posts

Wednesday, 19 September 2018

Office 365 OME setup mail encryption with a transport rule in Exchange Online

Office 365 offers multiple options for providing an encrypted mail service to users. Office 365 Message Encryption (OME) offers the best flexibility as Office 365 automatically trusts many of the main stream mail system providers for message decryption. S/MIME still requires a complex certificate exchange to be done between sender and recipient to ensure messages can be decrypted.
Mail providers Outlook.com, Yahoo and Gmail are automatically trusted by Office 365 and can automatically decrypt messages.
Other mail services which cannot automatically decrypt OME messages present a different set of challenges. One Time Passwords (OTP) are issued by Microsoft when an encrypted message is received by a mail server that cannot automatically decrypt messages. The OTP is sent directly from Microsoft to a user’s inbox (using the email address which was set as the recipient of the encrypted message). This way Microsoft can authenticate that only the intended recipient has received the OTP to decrypt the secured message.
Office 365 OME is a feature which is available in the following SKU’s Office 365 E3/E5, Microsoft E3/E5, A1, A3, A5 and G3/5. No licenses are required on the receiving side to accept encrypted mail. In this example we are going to make use of the Microsoft managed keys, however understand that it’s possible to BYOK to Azure Information Protection.
Go to the Azure Portal when you are logged in with your Office 365 credentials. Find Azure Information Protection from the portal. 

Click on Protection Activation, if this is not active, go ahead and activate it. 

Open the Exchange Admin Center and go to Rules. We are going to create a new Transport Rule to apply the encryption policy to emails that contain certain words. Click the + icon and select Apply Office 365 Message Encryption and Rights Protection to Messages.

Label the Transport Rule something sensible and click the Apply this rule if...and select The subject or body...then subject includes any of these words


Enter all the key words in which you want to be used to encrypt mail. I think it's generally good to use "encrypted", if you do this ensure you put in all the obvious spelling mistakes for "encrypted" so that users don't send clear-text messages because of typo's.

It's very easy to send encrypted email from Outlook with a Transport Rule in place to apply the encryption rule. Simply ensure the work "encrypted" is in the subject line, this words that is looks for before encrypting the message are user-defined in the steps above. 

When a recipient is also on Office 365 the message is automatically decrypted. You will notice the red marker to outline that this message is encrypted. Please note that when a single message (or reply) is encrypted, the entire conversation/message chain is encrypted.
If an encrypted message is viewable to a recipient, it's automatically opened into OWA. For some reason the message does not open directly in Outlook. This does ensure that the encrypted message cannot be forwarded. 

What happens if your send an encrypted email to a mail service which cannot automatically decrypted the message?


The encrypted message is opened in the browser.



The OTP is sent to the inbox.


The recipient can respond to the message securely in the browser.

Monday, 5 December 2016

Exchange Server 2013 CU13 Can't mount mailbox database "Unable to mount database. (hr=0x80004005, ec=1108"

Exchange Mailbox Database won't mount with the error "Unable to mount database. (hr=0x80004005, ec=1108" it turns out the transaction logs in this case are also corrupt, so the only option is to perform a hard database recovery. 

The /mh will show you the status of the EDB file, in my environment it was "dirty shutdown" which basically means not all the transaction logs were committed properly. 
  • ESEUTIL /mh ".edb path" - with quotes.
  • cd .edb location (the next command does not work unless you do this)
  • ESEUTIL /p ".edb file"
This perform a hard recovery on the Mailbox Database, in other words it does not attempt to copy in the old transaction logs it simply disregards that data and concentrates on repairing the EDB file. 

Before you try and mount the database it's important you remove the old transaction logs, I recommend moving them to a folder called "old" in their original location. If you do not do this the database will not mount.
  • Mount-Database "database name"
After this the db mounted without any issues. 

Thursday, 19 June 2014

Configuring Database Availability Group (DAG) in Exchange 2013 SP1

In this example I have two Mailbox Servers, and two Client Access Servers. I am going to configure a Database Availability Group. The official Microsoft description of a DAG, borrowed from TechNet.
 
 

DAG's work by replicating Mailbox Databases to neighbouring Mailbox Servers, deployed correctly this can create a highly resilient Exchange environment. Although Replication traffic can share the traditional MAPI network, it is considered best practise to separate the Replication traffic do it own network, either a subnet and/or VLAN.
 
I have provisioned my Mailbox Severs with two network adapters to support this configuration. It is important to name the adapters descriptively, as by default Exchange 2013 automatically configures the separate Replication network.
 
My adapters have been renamed Domain and Replication. The Domain interface is on the 192.168.1.0/24 subnet which is my production subnet that contains Domain Controllers, SCCM etc. The Replication interface is configured on the 196.100.10.0/24 subnet.
 
 
The Domain interface should be configured like it would on any other server, although as a Windows computer can only have a single default route (Default Gateway) the Replication interface should not be configured with a Gateway.
 
 
Click on the Advanced... button from the Internet Protocol Version 4 (TCP/IPv4) Properties page, and select the DNS tab. Untick the Register this connection's addresses in DNS.
 
 
As the Replication interface does not have a default gateway, a static route is required to provide a route to the rest of the subnet. The route add subnet mask subnetmask interface -p command to add this route. The -p switch ensures the route is persistent.
 
 
You can perform a route print to display the routing table on the server.
 
 
You will run into issues when creating the DAG, and adding DAG members if the bind order is not configured correctly. It is important the Domain interface is the primary connection.
 
 
The DAG itself must be represented in Active Directory, by the way of a Cluster Name Object. This is done by creating a disabled computer object. To do this open Active Directory Users and Computers, right click and select New, Computer name this object according. Please note when creating the DAG it must be named the same as the object.
 
 
As mentioned previously it's important the DAG computer object is disabled.
 
 
The security principal Exchange Trusted Subsystem is added to the ACL of the Cluster Name Object. It must also have Full Control access to this object. You can do this by using the Security tab on the properties of the object.
 
 
Now open the Exchange ECP and click Servers, Database Availability Groups. Click the + symbol to create a new DAG.
 
 
Now populate the fields with the corresponding information. Notice my mistake here, that will cause this to fail. My DAG is not named exactly the same as the Cluster Name Object, please ensure this is done properly. The File Share Witness is used as a tie breaker if servers suffer failure, if you do not specify a Witness server the wizard will automatically create it on one of the Client Access Servers. If you choose to configure your own File Share Witness, the Exchange Trusted Subsystem security principal must be in the local Administrators group of the server that is going to host the File Share. You will notice a Domain Controller cannot be a File Share Witness because DC's do not have local users and groups.
 
A DAG must also have an IP address, it is my recommendation to make this a static address even though the option is there to have DHCP assign an address dynamically.
 
 
Click Save and the DAG is created.
 
 
Now you must add DAG members to the DAG, this is done using the Add DAG Member button.
 
 
Click the + to add servers.
 
Select the Mailbox Servers you want to be part of the DAG, click Add and OK.
 
 
Click Save to commit the configuration.
 
 
 
By default Exchange automatically detects and configures the MAPI and Replication networks, there is not an obvious place in the GUI to show the MAP and Replication networks configuration. The PowerShell command Get-DatabaseAvailabilityGroupNetworks this shows how Exchange has configured the networking.
 
 
Now the DAG is created, with DAG members you must now configure Database Copies on the individual Mailbox Databases you want to be replicated by the DAG.
 
Click the ... icon and select Add Database Copy.
 
 
 
 
Specify the Mailbox Server you would like the Database replicated to. The Preference number is used to define a preference of where the database should be mounted while the DAG is operating normally. Click Save.
 
 
The wizard will now replicate the initial copy to the new DAG member server.
 
 
The Active button can be used when a server is selected to gracefully manage the failing over of what server is currently hosting the Mailbox Database. The Activate button will mount the Database on another DAG member and automatically redirect all connection, and it will also manage the reverse of the replication traffic. This can be useful if a server hosting a Mailbox Database requires updating or patching.