Exchange 2013 CU16 and Exchange 2016 CU5, both of these Exchange versions now require .NET framework 4.6.2 on all supported OS platforms.

As mentioned in the release posts for Exchange 2013 CU16 and Exchange 2016 CU5, both of these Exchange versions now require .NET framework 4.6.2 on all supported OS platforms.  This post focusses on Windows 2012 and 2012 R2 installations, see note below about Windows 2016.

Exchange setup will check for the presence of the required .NET framework, if not present setup will halt.

This is also true when extending the AD Schema and preparing Active Directory.  If the machine where you are running the AD preparation commands does not have the required .NET framework, then the installer will log an error.   In the below example a Windows 2012 R2 domain controller, the Schema Master FMSO role holder, was used to initiate the PrepareSchema command.  This failed due to .NET not being updated on that server where the Exchange 2013 CU16 setup command was being executed:

setup.exe /IAcceptExchangeServerLicenseTerms /PrepareSchema

Let us say if you are running Exchange 2013 CU 10 or Exchange 2016 CU2, you cannot apply the latest CU to your current Exchange 2013 or Exchange 2016 directly. You will go with two steps pf Exchange CU update or three Steps including the .net fromwork update:

For Exchange 2013

1. Apply Exchange 2013 CU 15 on your Exchange 2013 CU10 first,

2. Apply .net framework 4.62 and its security updates

3. Apply the latest Exchange 2013 CU, says CU 17 or CU18 coming soon in late 09/2017

For Exchange 2016

1. Apply Exchange 2016 CU 4 on your Exchange 2016 CU2 server first,

2. Apply .net framework 4.62 and its security updates

3. Apply the latest Exchange 2016 CU, says CU 6 or CU7 coming soon in late 09/2017

Reference:

https://blogs.technet.microsoft.com/rmilne/2017/03/27/exchange-2013-cu16-and-exchange-2016-cu5-net-framework-requirement/

How to determine which client to send email on Exchange

We had issue with meeting auto forward issue with Apple device bug that has apparently been fixed by the latest iOS 10.3.3. In order to figure out which client caused the auto forwarding,  here is the tip that explains how to determine which type of email client sent a particular email:

The good news is that the Message Tracking Logs, as expected, records this information. Every email sent has a SourceContext property which contains, amongst other information, the ClientType used to send the email. The important thing is to check this property for SUBMIT events, i.e., when the Mailbox Transport Submission service passes the email to the Transport service (in other words, when Exchange picks up the email from the mailbox's outbox folder and passes it on for delivery).

Please note that this only applies to emails sent by internal users! There is no SUBMIT event when an external sender sends an email to an internal user, meaning there is no ClientType property for these emails. 

 To check a particular email, we can run something like the following cmdlet and look at the SourceContext field:

Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 07/28/2017 -EventID SUBMIT -Sender user@xyz.com -MessageSubject "subject of the message" | ft SourceContext -auto -wrap

the output is something like:

MDB:5f3ad20c-4f7c-4336-b90b-80713daf208f, Mailbox:58d5fcea-e4eb-4546-b11e-4553bee5db46, Event:220387198,
MessageClass:IPM.Note, CreationTime:2017-07-28T09:19:48.649Z, ClientType:AirSync

So it's the iPad's activesync caused the forwarding for our case...

Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 07/28/2017 -EventID SUBMIT -Sender user@xyz.com -MessageSubject "subject of the message"  | ft SourceContext -auto -wrap

 This field will contain information like this:

MDB:34f3dc86-91bb-4ee7-a6a5-3d3ddc536050, Mailbox:a1de664f-9826-43a3-b9c8-3db019c86d8b, Event:29647741, MessageClass:IPM.Note, CreationTime:2017-07-28T07:17:14.922Z, ClientType:MOMT

 In this case, MOMT stands for MAPI on the Middle Tier, basically clients that connect using Outlook or any other application that connects using RPC/HTTP or MAPI/HTTP.

To count the number of emails sent using OWA for today, we can do something like:

(Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 07/28/2017 -EventID SUBMIT | ? {$_.SourceContext -match "OWA"}).Count

Exchange 2010 CAS server recoverserver failed due to different SID of the computer account

We shut down one of our Exchange 2010 CAS for a few months, Windows group thought we don't need it and killed VM and deleted Computer object. Although we can kill the server via ADSIeiditor, however,  that's the worst case of scenarios. Instead we asked Windows team to rebuild VM with the same version of OS, the same computer name and joint the domain,

we went over the prereqs for doing this, ran setup /mode:recoverserver option, the recovery mode finished 98% and failed to start MSExchangeADTopology services.

this is the error

 Client Access Server Role                                 FAILED
     The following error was generated when "$error.Clear();
          if ($exsSid -eq $null -or $exsSid -eq "")
          {
          $exsSid = get-ExchangeServerGroupSID -DomainController $RoleDomainCont
roller
          }
          start-setupservice -ServiceName MSExchangeADTopology -ServiceParameter
s $exsSid,$RoleDomainController
        " was run: "Service 'MSExchangeADTopology' failed to reach status 'Runni
ng' on this server.".


The Exchange Server setup operation didn't complete. More details can be found
in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.

Exchange Server setup encountered an error.

Rebooted the server, though MSExchangeADTopology service started OK, however, other services cannot be restarted.

So I tried to uninstall the server, and got error that the action of uninstall cannot continue since previous disaster recovery setup was not completed, please resume the disaster recovery maintenance or something like that. If I run setup /mode:recoverserver again and got the dame error as previously

I knew SID will cause the issue as we did disaster recover for Exchange 2003 servers previously. I did search cannot find any, until this one:

https://blogs./technet.microsoft.com/exchange/2007/05/21/how-does-exchange-2007-setup-know-to-resume-a-failed-setup/

By comparing with other working servers, I edit the register key as followings

 (Note: before do any modification of the reg key, we had better export the reg key to a file and do some screenshot as well)

1. delete the WaterMark string for sure

2. Delete Action string with DisasterRecover value

3. Create new Sting Reg_SZ called ConfiguredVersion with version number from UnpackedVersion value

After that, go to control panel -Program Features, remove the Exchange 2010 software, it failed at the first try for failed to stop the MSExchangeADTopology service. I tried to stop the service manually, it restarted the service automatically even I set it start manually, then I tried to disabled it and stop it, it still complained failed to stop the service. so I re-enabled the service and started it manually. this time, uninstalled finished completely successfully. Double check get-Exchangeserver, or Adsieditor, all entries for this server is gone. Well done,

  

IPSec Site to Site VPN Debug Command

Trying to identify VPN issues between two sites.

I've got the following enabled:

logging enable
logging buffered informational
logging trap informational
logging asdm informational
logging host switch.link 192.168.x.x
logging host switch.link 192.168.x.x
logging rate-limit 50 1 level 6

Normally you only run the debug commands when you are actually troubleshooting something. What I will do if I don't have a loging server available is to change the logging buffered to debugging and in SecureCRT (which is the terminal emulator I'm using) save the output on the screen to a text file and then search through that text file for the peer IP of the VPN etc.

If you run debugging level on buffered, trap and host at the same time it will burden the ASA quite significantly if there is a lot of output.

The best thing would be to have a linux based log server where you can use tools like grep to search through the output.

Exchange 2010 SP3 mailbox role installation with error exit code 87. Default mailbox database cannot mounted and copy status shown as "Service Down"

• I am in the process of installing Exchange Server 2010 SP3 on a Windows Server 2012 server in order to rehome Exchange 2010 Public folder servers to new hardware. Everything went well with the installation process until I went to add the Mailbox server role, which is giving me the following error (from the log file):

  [01/04/2017 21:58:09.0090] [1] Executing: 

            $wevtutil= join-path (join-path $env:SystemRoot system32) wevtutil.exe;

            $manifestPath = [System.IO.Path]::Combine($RoleInstallPath, "Scripts\TSCrimsonManifest.man");

            Start-SetupProcess -Name:"$wevtutil" -Args:"im `"$manifestPath`" "

          

  [01/04/2017 21:58:09.0105] [2] Active Directory session settings for 'Start-SetupProcess' are: View Entire Forest: 'True', Configuration Domain Controller: 'TAM-FS2.tacomaartmuseum.org', Preferred Global Catalog: 'TAM-FS2.tacomaartmuseum.org', Preferred Domain Controllers: '{ TAM-FS2.tacomaartmuseum.org }'

  [01/04/2017 21:58:09.0105] [2] Beginning processing Start-SetupProcess -Name:'C:\Windows\system32\wevtutil.exe' -Args:'im "C:\Program Files\Microsoft\Exchange Server\V14\Scripts\TSCrimsonManifest.man" '

  [01/04/2017 21:58:09.0276] [2] Starting: C:\Windows\system32\wevtutil.exe with arguments: im "C:\Program Files\Microsoft\Exchange Server\V14\Scripts\TSCrimsonManifest.man" 

  [01/04/2017 21:58:09.0344] [2] Process standard output: 

  [01/04/2017 21:58:09.0344] [2] Process standard error: The value for channel property Type contains an invalid value. The parameter is incorrect.

  
  

  [01/04/2017 21:58:09.0347] [2] [ERROR] Unexpected Error

  [01/04/2017 21:58:09.0347] [2] [ERROR] Process execution failed with exit code 87.

  [01/04/2017 21:58:09.0350] [2] Ending processing Start-SetupProcess

  [01/04/2017 21:58:09.0350] [1] The following 1 error(s) occurred during task execution:

  [01/04/2017 21:58:09.0350] [1] 0.  ErrorRecord: Process execution failed with exit code 87.

  [01/04/2017 21:58:09.0350] [1] 0.  ErrorRecord: Microsoft.Exchange.Configuration.Tasks.TaskException: Process execution failed with exit code 87.

  [01/04/2017 21:58:09.0351] [1] [ERROR] The following error was generated when "$error.Clear(); 

            $wevtutil= join-path (join-path $env:SystemRoot system32) wevtutil.exe;

            $manifestPath = [System.IO.Path]::Combine($RoleInstallPath, "Scripts\TSCrimsonManifest.man");

            Start-SetupProcess -Name:"$wevtutil" -Args:"im `"$manifestPath`" "

          " was run: "Process execution failed with exit code 87.".

  [01/04/2017 21:58:09.0351] [1] [ERROR] Process execution failed with exit code 87.

  [01/04/2017 21:58:09.0351] [1] [ERROR-REFERENCE] Id=MailboxComponent___13A8A6B7DE0A4fe3BEB5CB1D86105DA3 Component=EXCHANGE14:\Current\Release\PIM Storage\Content Indexing

  [01/04/2017 21:58:09.0351] [1] Setup is stopping now because of one or more critical errors.

  [01/04/2017 21:58:09.0351] [1] Finished executing component tasks.

  [01/04/2017 21:58:09.0393] [1] Ending processing Install-MailboxRole
• 
  

Although the installation ended with error exit code 87, the mailbox role seems installed already since all mailbox role's services are up and running... information store, mailbox replication services, etc. are installed and can be started with no issue. However, the default mailbox database cannot be mounted, copy status shows services down. We will have to fix it.

And the solution was:

• Fix this by removing the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Microsoft-Exchange-Troubleshooters/Operational and sub keys, then reinstall the mailbox rule once more time.  

That's nice, Microsoft, there is no KB about this.

Outlook 2016 - cannot view contents in shared mailbox inbox folders, but visible from OWA

There is a shared mailbox. users connect to the mailbox by adding it as an additional mailbox. It works fine. All suddenly, users reported they are no longer able to view contents of Inbox folders. " we don;t have any thing to display"

Here is the fix:

The way to change this option is the following:
 - menu "File"

 - "Account settings" -> "account settings..."

 - in the "E-mail" tab, select your account and then push the Change... button

 - push the "More settings..." button

 - go to the "Advanced" tab

 - in the "Cached Exchange Mode Settings" section, untick "Download shared folders"

If this options are already check, you need to do the opposite way to enabled both "Cached Exchange Mode Settings  and Download shared folders" options.