• On-premises Mailbox (Exchange 2010/2013/2016)
• Online Archive (EXO)
• Retention Policy (with “Move to archive” action)
• Litigation Hold On

• To enable online archive for an on premises mailbox, please follow the steps in “Create a cloud-based archive for an on-premises primary mailbox in an Exchange hybrid deployment”

• To automatically move items to archive, please create first the desired Retention Tags which will be part of the Retention Policy. I chose for my sample:

• To create the retention policy and add the tags to it

• To enable litigation hold indefinitely:

• To assign the newly created retention policy to the user:

• To immediately start messaging records management (MRM) processing of the mailbox, run:

• If you see that items are not moving to archive as expected please consider the following cmdlets for troubleshooting:

• Will the items in Recoverable Items folder in primary mailbox be moved to the Recoverable Items folder in archive after 2, 3 or 14 days? Items in the Recoverable Items folder in the primary mailbox will be moved to the Recoverable Items folder in the archive mailbox based on the settings in the Retention Policy Tags applying to the default Recoverable Items folder. In this scenario, the items in the Recoverable Items folder in the primary mailbox will be moved to the Recoverable Items folder in the archive mailbox after 3 days.

• Will a copy remain in primary mailbox until “RetaindeletedItemsfor” period is over? No, after the items in the Recoverable Items folder in the primary mailbox are moved to the Recoverable Items folder in the archive mailbox based on the settings in the Retention Policy Tags applying to the default Recoverable Items folder, there will not be any copy remaining in primary mailbox.

• How long will the recoverable items be kept in archive? If neither Litigation Hold nor InPlace Hold is enabled on the mailbox, recoverable items will be kept in archive based on the “RetaindeletedItemsfor” settings. Exchange saves the timestamp of when the item was moved to the Recoverable Items folder in the PR_LAST_MODIFICATION_TIME property of the item. The PR_LAST_MODIFICATION_TIME property will be updated too when the item in the Recoverable Items folder in the primary mailbox is moved to the Recoverable Items folder in the archive mailbox. In this sample-scenario, it will be 14 days. Default value of the “RetaindeletedItemsfor” parameter on the online archive is 14 days. For longer retention periods, Litigation/in-place holds should be considered.

• How long will the other remaining items be kept in the archive, after they are moved from primary mailbox? As described in Technet Archive mailboxes don't have a separate retention policy. The same retention policy is applied to the primary and archive mailbox.” Also as per Blog, “DPT with action other than move to archive action processes the primary mailbox as well as archive mailbox.” Therefore, if there are no additional tags in the primary mailbox (other than the two “MovetoArchive” tags), then the items in archive default folders should not be touched by other actions. So the remaining items (other than items in Recoverable items folder) should be kept for as long as the storage limit allows it, corresponding to your current plan (50GB/unlimited) https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx Please note however the following scenario: If the end-user applied a personal tag on a folder (let’s call it Folder1) and if a folder with the same name exists also in the Archive (Folder1), then the personal tag will be applied also to the folder in the archive due to the identical names. If the user does not want “Folder1” in the archive to be processed, then he should change the name of Folder1 in archive to something else. This scenario is explained also in the following article: https://blogs.technet.microsoft.com/vikass_blog/2013/07/03/retention-policy-on-archive-mailbox/

• If we place the primary mailbox on litigation hold, will the archive be placed on hold, too? Yes, as per TechNet : “If you place a Litigation Hold on an on-premises primary mailbox in an Exchange hybrid deployment, the cloud-based archive mailbox (if enabled) is also placed on hold.“  Also: “Litigation Hold preserves items in the Recoverable Items folder in the user's mailbox. The default size for this folder is 30 GB. Depending on number and size of items deleted or modified, the size of the Recoverable Items folder of the mailbox may increase quickly. The Recoverable Items folder is configured with a high quota by default. We recommend that you monitor mailboxes that are placed on Litigation Hold on a weekly basis to ensure they don't reach the limits of the Recoverable Items quotas".

• If we enable Litigation Hold on the primary mailbox (which will consequently enable Litigation Hold also on the Online Archive), will this cancel out the archiving retention policies applied on the mailbox which should actually "move content on the cloud", therefore releasing DB space On-Premise? Litigation hold or in-place hold is a compliance feature and is controlled from onprem and active for both mailboxes (primary and archive). The retention policy framework is a completely different feature that should stay working independently to in-place setup. Retention policies manage the part of the mailbox , that is visible to the user and handles how mails are moved to the archive. Litigation hold or in-place hold, keeps hard deleted mails in a hidden folder of the dumpster  – invisible to the user himself- (dumpster of both primary and archive) for compliance related search (eDiscovery). That means “move to archive” per retention policy should still work.

• If the Litigation Hold is a compliance feature in retaining items on both cloud archive and On-Premise, then how can this be the resolution for managing the space occupied by a mailbox that is still On-Premise? Indeed, if you place a Litigation Hold on an on-premises primary mailbox in an Exchange hybrid deployment, the cloud-based archive mailbox (if enabled) is also placed on hold. For managing the space issue, occupied by a mailbox on-Prem, you should use “move to archive” retention Tags. As explained above, the litigation hold feature will not interfere with the “move to archive” tags. See also article:

“Using the Recoverable Items 14 days Move to Archive retention tag helps free up storage space in the Recoverable Items folder in the user's primary mailbox. This is useful when a user's mailbox is placed on hold, which means nothing is ever permanently deleted the user's mailbox. Without moving items to the archive mailbox, it's possible the storage quota for the Recoverable Items folder in the primary mailbox will be reached.”

In other words, litigation hold just assures that no email is lost/deleted by users. Details.

• What happens right after the hard deletion of recoverable items (just before they are moved to the cloud)? Aren't they going to be placed under the Litigation Hold dumpster and stay there still occupying the same space they were occupying in the recoverable items dumpster (still inside the same On-Premise mailbox)? Items deleted from “Deleted items”, by user or by RPT, will go first to the Deletions in primary mailbox. But then no matter if they will reach the Purges folder or other recoverable items folder (still in primary mailbox), the retention action “move to archive” should still take place, as Recoverable Items tag should handle everything under Recoverable Items folder (Deletions, Purges, InPlaceHolds etc.).

• How can we restore recoverable items from the online archive back to the on-premises mailbox? As we know, there are various subfolders under Recoverable Items (no matter if primary mailbox/online archive).

• Items deleted from the Deleted Items folder, manually or by Retention Policy
• Items deleted by users from any folder by pressing Shift+Delete.

After reading the article written by Tzahi Kolber: Changing DAG & DAG members IP addresses we decided to use the actions described below.

The environment

They had a DAG with 4 nodes in two datacenters (EMEA and US) and a FSW in a third datacenter in EMEA. Also they wanted to switch from a single network card used by the DAG servers to 2 network cards, one for MAPI traffic and one for Replication.

All servers have the MBX/CAS roles.

Before making the changes

Table with IP addresses:

• Talk to all applications owners and notify them of the change. It is often that applications use the IP address of the servers rather than the VIP or the FQDN of the server.

• Make sure that the Old IP addresses are routable to the new MAPI IP addresses.

• Firewall rules should be updated in order to provide access to the new IP addresses.

The change

In our case we moved the nodes to different subnets so in this we needed to add Ips for the DAG in those subnets as well.

Set-DatabaseAvailabilityGroup –identity DAG -DatabaseAvailabilityGroupIPAddress 10.2.5.110, 10.2.6.110, 10.2.1.110, 10.2.3.110

1. We took the first server out of the HLB.

2. We moved all the active DBs to other nodes.

3. We’ve put the first node in maintenance mode as per article: https://blogs.technet.com/b/nawar/archive/2014/03/30/exchange-2013-maintenance-mode.aspx

4. Checked if the PAM was not hosted on the server where we did the changes:

Get-ClusterGroup

5. As the OwnerNode was the server on which we are doing the changes. We moved it using:

Move-ClusterGroup “Cluster Group” –Node [node where to move it]

6. Enabled the second NIC which will be used for replication. Configured the IP address, unchecked “Register this connection’s addresses in DNS”.

7. Set static routes for the Replication NIC.

8. Checked NIC bindings putting the MAPI network on top.

9. Switched the RDP connection to the Replication NIC and configured the IP address for the MAPI network.

10. Rebooted the server.

11. Check that we have the new IP in DNS and that it has replicated in the environment.

12. If you do a Get-DatabaseAvailabilityGroup | fl you should see:

13. Put the server in the HLB.

14. Pull out server from maintenance mode as per article: https://blogs.technet.com/b/nawar/archive/2014/03/30/exchange-2013-maintenance-mode.aspx

15. Move active databases on this server.

16. Repeat the previous steps on the other servers.

17. At the end do not forget to remove the old IPs for the DAG using:

Set-DatabaseAvailabilityGroup –identity DAG -DatabaseAvailabilityGroupIPAddress 10.2.5.110, 10.2.6.110

18. Disabled replication from the MAPI network.

Note: The above steps have been done for a DAG that had automatic DAG network configuration. The information regarding the networks is updated every 30 minutes.

As all major changes in a production environment you should test all the steps in a test environment in order to make sure you don't have any particular settings you need to take into consideration. 

Assuming we already have installed the Exchange and Edge server

I started by reviewing this TechNet article :

Configure Internet mail flow through an Edge Transport server without using EdgeSync

https://technet.microsoft.com/en-us/library/bb232082%28v=exchg.150%29.aspx

But I think it lacks some information regarding the certificate issues we might run into.

On the Edge server I created the Send/Receive connectors :

New-SendConnector -name "Outbound" -AddressSpace * -Usage Internet -DNSRoutingEnabled $true

$MailboxCredentials = Get-Credential

New-SendConnector -name "To Wingtip Internal" -Usage Internal -AddressSpace *.wingtiptoys.com -DNSRoutingEnabled $false -SmartHosts Wingtip-e2k13.wingtiptoys.com -SmartHostAuthMechanism BasicAuthRequireTLS -AuthenticationCredentiaI $MailboxCredentials

Set-ReceiveConnector "Default internal Receive connector Wingtip-Edge2013" Name "From Internet" -Bindings 10.1.1.200: 25

New-ReceiveConnector -Name "From WingtipOrg" -Usage Internal -AuthMechanism TLS, BasicAuthRequireTLS, ExchangeServer -Bindings 192.168.0.202:25 -RemoteIPRanges 192.168.0.113

To verify everything was set successfully use : 

Get-SendConnector I Format-List Name , Usage , AddressSpaces , SourceTransportServers , DSNRoutingEnab1ed , SmartHosts , SmartHostAuthMechanism

Get-ReceiveConnector I Format-List Name, Usage, AuthMechanism, Bindings, RemotelPRanges

I also made sure that I am able to resolve DNS names so I added some entries in the Hosts file

At this point you have two options :

 - create a certificate with a 3rd party Certificate Authority

 - create a certificate in the Local Certificate Authority

I chose the second option to work with the Local Certificate Authority.

On the Exchange 2013 server I created a certificate request and included the usual host names I would need, because I want to use this certificate on all services I included more subject alternative names. You have the option to only use the certificate for SMTP communication so you will only need to have both host names in the SAN.

Here is the certificate I created :

New-ExchangeCertificate -PrivateKeyExportable:$true -FriendlyName 'wingtipmail3' -SubjectName 'C=US,S="WA",L="Seattle",O="Wingtiptoys",OU="IT",CN=Wingtiptoys.com' -DomainName @('wingtip-e2k13.wingtiptoys.com','AutoDiscover.Wingtiptoys.com','Wingtiptoys.com','wingtip-edge13.wingtiptoys.com','smtp.wingtiptoys.com','owa.wingtiptoys.com','wingtip-e2k7.wingtiptoys.com','wingtip-e2k10.wingtiptoys.com') -RequestFile '\\wingtip-dc\cert\edgenew2.req' -GenerateRequest:$true -Server 'ba68d970-aaa2-44dd-b303-f2666ea1d8b9' -KeySize '2048'

I went to the Local Certificate Authority and issues the certificate that I enabled for SMTP service

Enable-ExchangeCertificate 6B138B7F7492A3E57BCAD0813BA67CC58DAEF805 -Thumbprint -Services SMTP

Because I haven't added the certificate on the Exchange 2013 EDGE server I was receiving the error : "SubjectMismatch, Chain validation status"

I then added the certificate on the Exchange 2013 EDGE server and enabled the certificate for SMTP TLS communication.

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certificates\ExportedCert.pfx -Encoding byte -ReadCount 0)) -Password:(Get-Credential).password

Restarted Microsoft Exchange Transport service on the Microsoft Exchange 2013 EDGE server

I now get the error "UntrustedRoot, Chain Validation Status"

This is because on the Exchange 2013 Edge server I haven't installed the RootCA certificate and CRL Revocation list from the Local Certificate Authority.

Using PKI on the Edge Transport Server for Domain Security

https://technet.microsoft.com/en-us/library/bb124817%28v=exchg.141%29.aspx

You should be able to get this from the Certificate Authority server \\Server\CertEnroll\

Here is what I found

To import this certificate and revocation list please start mmc.exe and add Certificates Snap-in for the Computer Account.

The Root Certificate will be installed in Trusted Root Certificate Authorities with Import

The Certificate Revocation List will be installed in Intermediate Certificate with Import

After I installed the Root certificate and CRL list I had another issue as the credentials I was using to authenticate on the Edge server were not accepted so I had to create a new Local User and add it to Administrators group on the Microsoft Edge 2013 server to use on the Send connector from the Exchange 2013 server.

I am now able to relay emails through my Exchange 2013 Edge server using BasicAuthRequireTLS

If you have any questions please feel free to send an email to cristi.timofte@microsoft.com

If your organization has 2 major tenants under which user population is getting migrated, since the users would be placed into 2 different tenants free/busy information sharing is not enabled by default. Following document introduces the options and steps which are needed in order to have the Free/busy information shared between 2 tenants.

What is Free/Busy data?

Free/busy data is information about the availability of individuals within an organization at specified times. The user status data indicates whether the time period specified is free, busy or tentative, or if the user has set their out of office status. However, the data contains no explanatory information, such as whether the user is in a meeting or has a personal appointment or whether they are physically in the office at the requested time.

What is the Organization relationship?

In order to setup a free/busy sharing between the two tenants, it is required that a New organization relationship needs to be created - An organization relationship is a one-to-one relationship between businesses to allow users in each organization to view calendar availability information. When it is set up, Administrator is actually setting level of information that the users in the external organization can view. The external organization may set up the same or different settings on their side.

Scope of this article:

This article only covers the steps that are required in order to enable Free/Busy information sharing between the Office 365 users from two different tenant. This articles does not cover the topic of sharing the On-Premise Free/Busy information with Office 365 users or On-premise to On-Premise Free/Busy sharing between two hybrid infrastructures.

This articles covers the activation of Free/Busy information between ContosoEU.onmicrosoft.com (a European tenant) and ContosoNA.onmicrosoft.com (a North America tenant).

Configuration Part:

Configuration of the free/busy information can be broken into two part and those are:

a) Initial configuration

b) Managing the configuration

Initial Configuration:

Following are the steps which can be followed in order to setup the Organization relationship.

On the European tenant

1. From the Office 365 admin center dashboard, go to Admin > Exchange.
2. Go to Organization > Sharing.
3. Under Organization Sharing, click New .
4. In New organization relationship, in the Relationship name box, type a friendly name for the organization relationship as “Contoso EU to Contoso NA tenant”
5. In the Domains to share with box, type the domain for the external Office 365 or Exchange on-premises organization as ContosoNA.onmicrosoft.com.
6. Select the Enable calendar free/busy information sharing check box to turn on calendar sharing with the domains. Set the sharing level for calendar free/busy information and set which users can share calendar free/busy information.

To set the free/busy access level, select one of the following:

• Calendar free/busy information with time only.
• o   Calendar free/busy with time, subject, and location.

1. Click save to create the organization relationship.
2. Once the setup is completed, Organization relationship should show up the following information auto populated into it.
3. Also make sure that all the federated domains are well populated into the Organization relationship.

On the US tenant:

1. From the Office 365 admin center dashboard, go to Admin > Exchange.
2. Go to organization > sharing.
3. Under Organization Sharing, click New .
4. In new organization relationship, in the Relationship name box, type a friendly name for the organization relationship as “Contoso NA to Contoso EU tenant”
5. In the Domains to share with box, type the domain for the external Office 365 or Exchange on-premises organization as contosoeu.onmicrosoft.com
6. Select the Enable calendar free/busy information sharing check box to turn on calendar sharing with the domains. Set the sharing level for calendar free/busy information and set which users can share calendar free/busy information.

To set the free/busy access level, select one of the following:

• Calendar free/busy information with time only.
• Calendar free/busy with time, subject, and location.

1. Click save to create the organization relationship.
2. Once the setup is completed, Organization relationship should show up the following information auto populated into it.                         
3. Also make sure that all the federated domains are well populated into the Organization relationship.

Managing this configuration:

When the initial setup is completed, it would be necessary to make sure that all the new domains which are getting added into the O365 are participating into the Organization relationship and in order to update the information onto the Organization relationship here are the steps.

1. From the Office 365 admin center dashboard, go to Admin > Exchange.
2. Go to organization > sharing.
3. Double click on the Organization Relationship which has been created – type in the domain name into the section “Enter a domain here” and Press + button
4. Click save to complete configuration

How to know if this has worked:

After the configuration is completed Free/busy availability details should be visible across both the tenants –any O365 users in the EU or NA tenant should be able to see the free/busy information of any EU/NA tenant user.

How does the Organization Relationship works in this scenario?

By creating the organization relationships with the vanity domains, all the Office 365 users from these two tenants will be able to see their Free/Busy information, based on the MFG token and here is the flow of how it actually works.

1. A user who is in the ContosoEU tenant requests Free/Busy information for User1@contosona.com (which is on the NA tenant) This request is made at the Exchange online.
2. The Exchange online will now lookup its organizational relationships and verify if it has one for contosona.com.
3. Now, the Exchange online will contact the Microsoft Federation Gateway and request an authentication token for contosona.com.
4. The MFG sends back a token because contosona.com has a trust relationship with the MFG.
5. The Exchange Online now uses the information it obtained from the Organization Relationship to do an Autodiscover request for this domain, in order to retrieve the remote Exchange Web Services endpoint it should connect to. It then uses the address that is received to send the Free/Busy request to.
6. Exchange Online of the NA tenant will first check whether the MFG token which the Exchange EU tenant has sent across with is valid before accepting the Free/Busy Request.
7. It will also verify its organization relationship so that it knows what information it is allowed to return.
8. Once the above checks are completed, the mailbox of User1@contosona.com will be queried for the Free/Busy information.
9. Exchange Online of NA tenant will send back the Free/Busy information to the EU tenant, once it will be successfully obtained.

“Every day brings a new challenge…”

I am still convinced, that whoever said that first, was an Exchange Server Administrator…

If you wake up one day and find these two beautiful events in your Application Logs, no need to wonder:

4133 Database one datacenter health check failed.

4376 Database one datacenter available copy health check failed.

Log Name:      Application

Source:        MSExchangeRepl

Date:          …

Event ID:      4133

Task Category: Service

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      …

Description:

Database one datacenter health check failed.

Database copy: …

Redundancy count: 2

Error:

================

Full Copy Status

================

…

Log Name:      Application

Source:        MSExchangeRepl

Date:          …

Event ID:      4376

Task Category: Service

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      …

Description:

Database one datacenter available copy health check failed.

Database copy: …

Redundancy count: 2

Error:

================

Full Copy Status

================

…

After performing some tests in our Exchange 2013 test environments, we managed to find out that these events could be expected in the following scenario:

• spanned DAG over multiple physical locations but in one AD site, containing at least 2 nodes

• created Passive copies for the DBs

• enabled DAC Mode for DAG (DagOnly)

   

  Results:

• These errors were thrown only after enabling DAC Mode on the DAG (errors started to be thrown for all DBs and all their copies that existed on nodes in the same AD site)

• Please note that these errors can be thrown also in a scenario where DAG members are split over 2 or more AD sites, but where Databases are replicated only over nodes in the same AD site.

What to do?

1. Not to panic! These events can be safely ignored. They do not refer to any issues with the DAC mode, nor with replication between nodes.

    *** Please make sure however that you are not hitting another issue. You must check the “Error” Section in the description of these events (both Event ID 4133 and 4376). In our case described in this blog, you will see this Error Section is empty:

    

   

    

   If this section is not empty, but populated with extra information, as in the screenshot below, please troubleshoot it separately, as this is not our scenario:

    

    The information in this Error section might indicate real issues which need further investigation. So please do not ignore the events, if this error section is populated.

    

2. You can disable the DAC mode (these errors will not be logged anymore, if DAC mode disabled)

3. You can span the DAG members on two AD Sites and make sure each DB has a copy in each site, the errors will not be logged anymore.

4. You can wait for CU7, as there are plans to change the design in a way that will not log these errors in the Application Logs any more but in the „Monitoring“ Crimson Channel Log and that will add relevant text in the Error section in these events, so that you can have a better understanding of their cause.

As we have introduced Anti-malware filtering by default in Exchange 2013 we have noticed that some Exchange servers fail to update the engines.

We do have a couple of scripts designed to manage Anti-malware filtering, all these scripts are located in the Scripts folder of Exchange 2013 so you have to go the folder by using :

cd $ExScripts

Available scripts
.\Disable-AntiMalwareScanning.ps1
.\Enable-AntiMalwareScanning.ps1

After running any of the above scripts you have to restart "MSExchange Trasport" service by running :

Restart-Service MSExchangeTransport

To manually force an update you can use the .\Update-MalwareFilteringServer.ps1 script

.\Update-MalwareFilteringServer.ps1 <Server_Name>

To verify that updates were successfully downloaded, check the event log:
1. Open Event Viewer;
2. In Event Viewer, expand the Windows Logs folder, and then click Application;
3. In the Actions menu, click Filter Current Log;
4. In the Filter Current Log dialog box, from the Event sources drop-down list, select the FIPFS check box, and then click OK.
If engine updates were downloaded successfully, you will see an Event ID 6033 similar to the following:

If the engine updates fail, you will see an Event ID 6027 similar to the following :

How to troubleshoot this issue ?

We will start by making sure there is no Proxy rule so just open your browser and open

https://forefrontdl.microsoft.com/server/scanengineupdate/

This is the page that should be returned

What we will do to solve Event ID 6027 is to create a centralized server for downloading and distributing the malware engines.

After deciding on what server you will store the malware engines please create a local directory structure on the computer on which you want to download the scan engine updates. To do this, follow these steps:
 a. Create a directory. For example, create a directory that is named "ScanEngineUpdates."
 b. Set the NTFS file system and share permissions on the directory so that the exchange servers and "NT AUTHROITY\Network Service" have access to the directory.
 
Please visit the below KB article to download the Update-Engines.ps1 Powershell script
https://support.microsoft.com/kb/2292741

Execute the Update-Engines.ps1 Powershell script, providing any necessary parameters. The format of the command is as follows:
Update-Engines.ps1 -EngineDirPath <string> -UpdatePathUrl <update url> -Engines <engine names> -Platforms <platform names>
 o EngineDirPath <string> The directory to serve as the root engines directory, created in step 2. This is a required parameter
 o UpdatePathUrl <update url> The update path used to pull the updates from
 o Engines <engine names> The list of names of engines to update
 
Note: Multiple engine names should be separated by commas, with or without spaces.
Platforms <platform names> The list of names of platforms to update
 
Update-Engines.ps1 -EngineDirPath C:\ScanEngineUpdates\
Update-Engines.ps1 -EngineDirPath C:\ScanEngineUpdates\ -UpdatePathUrl https://forefrontdl.microsoft.com/server/scanengineupdate/ -Engines Microsoft -Platforms amd64, x86
Update-Engines.ps1 -EngineDirPath C:\ScanEngineUpdates\ -UpdatePathUrl https://forefrontdl.microsoft.com/server/scanengineupdate/ -Engines Microsoft -Platforms amd64, x86
 
You can now configure Exchange servers to download updates from the directory created
 
Open a PowerShell window on the Exchange server where you want to distribute the engine
 
Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell
 
Set-EngineUpdateCommonSettings –SecondaryUpdatePath \\server\ScanEngineUpdate\

This will be removed at the next server reboot. To make this change permanent please use :

Set-MalwareFilteringServer -PrimaryUpdatePath \\server\ScanEngineUpdate\

Start-EngineUpdate
 
To verify if the Engine Update was successful you can run

Get-EngineUpdateInformation | fl

If the update fails we will see the UpdateStatus : UpdateAttemptFailed and we will also have the Event ID 6027

If the above will not resolve your issue check that "NT AUTHROITY\Network Service" has full access for the folder Program Files\Microsoft\Exchange\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin, in case you have installed Exchange in different drive, you need to add "NT AUTHROITY\Network Service" on the drive itself.

If you have closed the Exchange Powershell you have to add the ForeFront PSSnappin again to have access to Forefront cmdlets.

Add-PSSnapin -Name Microsoft.Forefront.Filtering.Management.PowerShell

Start-EngineUpdate

Restart Microsoft Filtering Management Service.

After few minutes update will be finished and if you run Get-EngineUpdateInformation again it should show if it was updated.

If the above fail the final way to get this solves it to manually add the files to the FIP-FS folder

Download latest manifest file (xml compressed in cab file) from https://forefrontdl.microsoft.com/server/scanengineupdate/x86/Microsoft/Package/manifest.cab

Unpack manifest.xml and verify engine number - for today and change the number with red from the link below :

Download  https://forefrontdl.microsoft.com/server/scanengineupdate/x86/Microsoft/Package/1408070001/Microsoft_fullpkg.cab and unpack to a separate folder somewhere on disk.

Open C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin (if you installed Exchange with default path)

Do a backup of the existing files first in the above folder and the copy the files unpacked from the cab file to this folder.

Restart Microsoft Filtering Management Service.

After few minutes your first update will be finished and if you run Get-EngineUpdateInformation again it should show you actual data.

Make sure "NT AUTHROITY\Network Service" has full access for the folder Program Files\Microsoft\Exchange\V15\FIP-FS\Data\ in case you have installed exchange in different drive, you need to add "NT AUTHROITY\Network Service" on the drive itself.

For any questions please feel free to contact me.

Cristi Timofte
cristi.timofte@Microsoft.com

In laymen terms we will have two groups of administrators:

1) The first group is able to access any database and perform actions on it (we will call this group the “special administrator”)

2) The second group has absolutely no access on what we will call our “special database” but can perform actions on regular databases, he’s the normal administrator.

For this scenario, we have defined two databases, DB being a regular database and RBAC-DB being the “special database” that should only be accessed by the “special” administrator.

To understand the topology a little better:

Our “special administrator” is called Admin, and has all the necessary administrator permissions:

We start with the basic scope on the database level, an exclusive scope as opposed to a regular scope, because we want Admin to have access to RBAC-DB (and all other DBs) and Administrator to have access to all DBs but not RBAC-DB. For this we use the below cmdlet:

New-managementscope –Name “RBAC-DB” –DatabaseList: RBAC-DB -Exclusive

You can see that the ScopeRestrictionType is set to DatabaseScope, as I have named these databases with the parameter –DatabaseList. However the same should be achievable also on Server level, in which you just use the parameter –ServerList.

As soon as the scope has been defined, we need to introduce the Role Assignments, which basically tie the Scope to the Role Entry and to the Person being assigned the scope (can be a Role Group, Security Group or a single User), as observed in the below picture:

In order to do this you need to think about what your administrator is allowed to do. If you want a better overview of what he “can” do, just run the bellow cmdlets:

Get-ManagementRoleAssignment |fl *Role* or use any other filter to get the necessary information.

The list can be quite long, as we have a substantial number of Role Assignments created by default in Exchange 2010, but you can also have a quick look at the TechNet article describing Management roles assigned to this role group:

Organization Management: https://technet.microsoft.com/en-us/library/dd335087(v=exchg.150).aspx

What we want to see is that when the normal administrator tries to access the “special DB” in any way, he gets the bellow error message, as opposed to our “special admin” being able to complete any actions he wants:

We want our administrator to have all the necessary permissions a normal administrator has, so we will use the bellow Management Role Assignments:

New-ManagementRoleAssignment –Name “Config-Databases” –Role Databases –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

Test results so far:

Note: PowerShell and the Exchange Management Console need to be restarted for the changes to be applied!

We are not satisfied with these results yet, the special administrator’s actions should be all green on the special DB.

Hence we are adding a second Role Assignment, as the error messages we are getting show us that we don’t have the necessary access rights yet:

For example, the below management role assignment allowed my special administrator to create mailboxes on the special DB without getting the error message.

New-ManagementRoleAssignment –Name “VIP Recipient Creation” –Role “Mail Recipient Creation” –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

 For a quick reference of what a RoleEntry exactly contains, you can run the cmdlet “Get-ManagementRoleEntry “Mail Recipients\*”, for example.

As an Exchange Administrator, I want to take advantage of what a DAG has to offer, so I need to make sure that I will still be able to run the DAG cmdlets:

This RoleAssignment allows us to:

New-ManagementRoleAssignment –Name Moves –Role “Move Mailboxes” –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

Test results so far:

Upon doing another move test, the results remained the same. The reason for this escaped me until I realized that the move action is done on a recipient level.

At this point I realized we need to introduce a second Management Scope, to be able to include a set of cmdlets found only under Recipient Scopes (we noticed that we cannot do mailbox moves or mailbox imports and exports just with the above configuration).

Basically the cmdlets in the roles "Move Mailboxes" and "Mailbox Import Export" only work at a recipient level, which is why we need to add a Recipient Scope to our Database Scope.

New-ManagementScope -Name “VIP_Scope” -RecipientRestrictionFilter { MemberOfGroup -eq ‘Thresh.com/Users/VIP’ } –Exclusive

For this new scope we add the three Role Assignments, to be able to complete our necessary set of actions, as follows:

New-ManagementRoleAssignment -Name “Recipient Creation” -Role “Mail Recipient Creation” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

New-ManagementRoleAssignment -Name “VIP_Move_Mailboxes” -Role “Move Mailboxes” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

New-ManagementRoleAssignment -Name “VIP_ Import_Export” -Role “Mailbox Import Export” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

Upon further testing, the results are really good:

To sum things up, what makes the difference:

1 Scope on DB level set on RestrictiveRecipientConfigScope + ManagementRoleAssigments:

New-ManagementRoleAssignment –Name “Config-Databases” –Role Databases –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

New-ManagementRoleAssignment –Name “VIP Recipient Creation” –Role “Mail Recipient Creation” –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

New-ManagementRoleAssignment –Name Moves –Role “Move Mailboxes” –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

1 Scope on Recipient level set on RestrictiveRecipientWriteScope + ManagementRoleAssigments:

New-ManagementRoleAssignment -Name “Recipient Creation” -Role “Mail Recipient Creation” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

New-ManagementRoleAssignment -Name “VIP_Move_Mailboxes” -Role “Move Mailboxes” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

New-ManagementRoleAssignment -Name “VIP_ Import_Export” -Role “Mailbox Import Export” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

+ You need to consider what necessary Management Scope Assignments need to be added for further functionalities to work. I recommend testing the environment before deployment as it's quite a tricky configuration.

Consider the following scenario: in Exchange 2010 you have some old mail-enabled public folders migrated from Exchange 2003. You notice that editing AD permissions such as Send As on these folders fails. So you are logged in with an account that’s member of Organization Management, you go in Exchange Management Console – Toolbox - Public folder Management Console, select the public folder that you would like to adjust the Send As Permissions on, you choose Manage Send As Permission and select a user to add. At this moment you have an error:

The directory operation failed on "FolderName". This error is not retriable.

Additional Information: Access is denied. The directory response 00000005: SecErr: DSID-031521D0, problem 4003

(INSUFF_ACCESS_RIGHTS),

The user has insufficient access rights.

Add-Adpermission –identity “DN of the Public Folder AD Object” –ExtendedRights “Send-as”

If you look closely at Active Directory security settings on these public folders, you will notice that the owner is still the decommissioned Exchange 2003 server. In order to check this, go in ADSIEdit – Default Naming Context - DC=domain,DC=com,CN=Microsoft Exchange System Objects, right-click on the mail-enabled public folder, Properties – Security – Advanced – Owner tab.

This is a known issue for migrated mail-enabled public folders. The issue is fixed in Exchange 2013, and for Exchange 2010 the workaround is pretty simple: just mail-disable / mail-enable the public folder and the issue is gone.

For those who, for some reason, are not able to mail-disable their public folders, the second workaround is to manually change the owner of those PF in ADSIEdit (follow the same path as above) – you can simply replace it with Exchange Servers. 

All users started to complain that they are unable to perform a download of the offline address book and they are hitting the following message in Outlook “Unknown Error 0x80070422”:

Naturally we’ve started the investigation by examining the OAB generation Server (that’s what you should first do and check that is working properly) and couldn’t find anything wrong or suspicious even after raising event logging for the MsExchangeSA/OALgenerator to expert.

Afterwards we examined the Client Access Servers, specifically the OAB Folders

<C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OAB>

And could see that they were up-to-date with the generation server, meaning that the “file distribution service” on the CAS were doing their job to copy the files from the mailbox server.

Next we decided to decode the actual client error code 0x80070422 which translates to the following:

 “The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.”

Following this we decided to check the services console on the outlook client machine and we could observe that the “Background Intelligence Transfer Service” was explicitly disabled via Group Policy.

If the Outlook Client was running in online mode, an attempt to download the OAB would result in the following error message: "An error occurred while opening the Microsoft Exchange Offline address book files on the Microsoft Exchange Server.  See your administrator."

Note: Even if the BITS Service is stopped, Outlook would start it on demand when attempting to download the address book. Should the service be explicitly disabled, it would no longer be able to start on demand and fail thus throwing the error message “Unknown Error 0x80070422”

For more information see the following KB Articles:

https://support.microsoft.com/kb/2429946  How to troubleshoot the Outlook Offline Address Book in an Office 365 environment

https://technet.microsoft.com/en-us/library/bb232155(v=exchg.141).aspx  Understanding Offline Address Books

However, when coming to the implementation or defining different management roles and entries, management groups, things are not every time that clear.

By default, each user has the “Default Role Assignment Policy”, which grants the users permissions to set their Outlook Web App options and perform self-administrative tasks.

The policy above includes the MyDistributionGroups role assigned - this role enable individual users to create, modify and view distribution groups and modify, view, remove and add members to the distribution groups they own.

Let’s say we want individual users to be able to perform specific actions on distribution groups they own, even if the groups are hidden from the Global Address List. Therefore, we have to create a custom management role, based on the Distribution Groups management role, which enable administrators to create and manage groups and distribution group’s members in the organization. Moreover, we have to compare the actions available to the MyDistributionGroups role, remove the extra permissions, and make an adjustment to make sure it will comply with our needs.

To implement a solution based on an existing RBAC management role group, we can follow the steps below.

1.       First, we create a new custom management role, which basically is a collection of actions (commands) we can perform having the role assigned, based on built-in role Distribution Groups using the following command:

New-ManagementRole -Name "Distribution Groups ManagedBy" -Parent "Distribution Groups"

2.       We compare then the management role entries (cmdlets) provided by the new custom role and the MyDistributionGroups default role.

We need this information to remove cmdlets and cmdlet parameters we don’t want to make available via the custom management role.

First, we determine the cmdlets of the custom role using the command:

Get-ManagementRoleEntry "Distribution Groups ManagedBy\*" | Format-Table name

Name

----

Add-DistributionGroupMember

Disable-DistributionGroup

Enable-DistributionGroup

Get-ADServerSettings

Get-AcceptedDomain

Get-DistributionGroup

Get-DistributionGroupMember

Get-DomainController

Get-DynamicDistributionGroup

Get-Group

Get-MailUser

Get-Mailbox

Get-OrganizationalUnit

Get-Recipient

Get-ResourceConfig

Get-User

New-DistributionGroup

New-DynamicDistributionGroup

Remove-DistributionGroup

Remove-DistributionGroupMember

Remove-DynamicDistributionGroup

Set-ADServerSettings

Set-DistributionGroup

Set-DynamicDistributionGroup

Set-Group

Set-OrganizationConfig

Update-DistributionGroupMember

Write-AdminAuditLog

Now run the following command to list the cmdlets for the MyDistributionGroups role:

Get-ManagementRoleEntry "MyDistributionGroups\*" | Format-Table name

Name

----

Update-DistributionGroupMember

Set-Group

Set-DynamicDistributionGroup

Set-DistributionGroup

Remove-DistributionGroupMember

Remove-DistributionGroup

New-DistributionGroup

Get-Recipient

Get-Group

Get-DistributionGroupMember

Get-DistributionGroup

Add-DistributionGroupMember

By comparing the two lists, we can determine the cmdlets that are not provided by the MyDistributionGroups role. If we want a new RBAC group based on the default distribution group, we have to remove the additional role entries inherited from the Distribution Groups parent entries.

3.       Using the Remove-ManagementRoleEntry command, we remove the cmdlets that are not required from the custom role.

The example below removes the Disable-DistributionGroup cmdlet:

[PS] C:\>Remove-ManagementRoleEntry "Distribution Groups ManagedBy\Disable-DistributionGroup"

Confirm

Are you sure you want to perform this action?

Removing the "(Microsoft.Exchange.Management.PowerShell.E2010) Disable-DistributionGroup -Confirm -Debug

-DomainController -ErrorAction -ErrorVariable -Identity -IgnoreDefaultScope -OutBuffer -OutVariable -Verbose

-WarningAction -WarningVariable -WhatIf" management role entry on the "Distribution Groups ManagedBy" management role.

[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y

We repeat the command above until we to remove all the cmdlets we don't need. Additionally we also remove the New-DistributionGroup cmdlet, to remove the ability to create new distribution groups.

4.       We can also determine and remove cmdlet parameters not required on the remaining cmdlets.

As before, we can compare the parameters of each cmdlet for MyDistributionGroups with the ones not included in the cmdlets of the custom role.

Use the following command to display the list of parameters for each cmdlet. In the example bellow, the parameter for the Add-DistributionGroupMember are listed:

(Get-ManagementRoleEntry "MyDistributionGroups\Add-DistributionGroupMember").parameters

Confirm

ErrorAction

ErrorVariable

Identity

Member

OutBuffer

OutVariable

WarningAction

WarningVariable

WhatIf

Repeat this for the same cmdlet from the custom created Distribution Groups ManagedBy role:

[PS] C:\>(Get-ManagementRoleEntry "Distribution Groups ManagedBy\Add-DistributionGroupMember").parameters

Confirm

Debug

DomainController

ErrorAction

ErrorVariable

Identity

Member

OutBuffer

OutVariable

Verbose

WarningAction

WarningVariable

WhatIf

5.       Remove the parameters from the custom role entries. Once you have the list of the parameters to be removed, use the Set-ManagementRoleEntry command to remove them. In the example bellow, the Debug, DomainController and Verbose parameters are removed from the Add-DistributionGroupMember cmdlet:

Set-ManagementRoleEntry "Distribution Groups ManagedBy\Add-DistributionGroupMember" -Parameters Debug, DomainController, Verbose –RemoveParameter

Repeat these steps for all the cmdlets that have parameters that are not part of the entries used in default role.

6.       Once we have the desired cmdlets and parameters customized for our management role, we can assign it to an user or a role group. Rather than assigning a management role directly to a user, we can assign it to a role group, where we can add the user who need to perform specific actions.

The following command creates a new role group, called ManageBy Group and assigns the custom management role we have created and customized:

New-RoleGroup -Name "ManagedBy Group" -Roles "Distribution Groups ManagedBy"

This command results in the creation of the role group, and also of a role assignment called Distribution Groups ManagedBy-ManagedBy Group. This assignment uses the implicit scope of the custom management role for the recipient write scope, which is inherited from the parent default scope. We can see the scope by using the following command:

Get-ManagementRoleAssignment -Role "Distribution Groups ManagedBy" | Format-List Name, *RecipientWriteScope

Name : Distribution Groups ManagedBy-ManagedBy Group

CustomRecipientWriteScope :

RecipientWriteScope : Organization

Notice the RecipientWriteScope is set to Organization which is too broad for an assignment. The scope must be changed so that it allows a user to manage only the distribution groups they own. The following command sets the recipient relative write scope to MyDistributionGroups.

Set-ManagementRoleAssignment "Distribution Groups ManagedBy-Distribution Group ManagedBy" -RecipientRelativeWriteScope MyDistributionGroups

7.     We make a functionality test for the role assignment. Added an user to the role groups created in step 6 and opened the ECP.

The user has a broader read scope that allows him to see the hidden objects, when managing distribution groups owned.

Following the steps above we can create different RBAC roles, groups and assignments to suits our Exchange organization goals.

I hope you find the information useful,

        Gabriel MUNTEAN