The requested HTTP URL was not available

While trying to setup Remote PowerShell to an Exchange 2013 Server I ran into a couple of issues. The most obvious was that the Exchange server only accepts SSL request, so you have to specify ‘https’ in the ConnectionUri, so I used these commands:

$Credential = Get-Credential administrator@posh.local
$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri https://webmail.posh-workshop.com/PowerShell -Authentication Basic -Credential $Credential -AllowRedirection
Import-PSSession $Session

The following error was returned:
New-PSSession : [webmail.posh-workshop.com] Connecting to remote server webmail.posh-workshop.com failed with the following error message : The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. For mor e information, see the about_Remote_Troubleshooting Help topic.

image

When checking the PowerShell virtual directory using the Get-PowerShellVirtualDirectory | fl command I got the following response:

image

When you want to use Remote PowerShell from a non domain member (or via the Internet) you have to use Basic Authentication (as specified in my request), you also have to set Basic Authentication on the Virtual Directory as well, like this:

Get-PowerShellVirtualDirectory –Server MAIL01 | Set-PowerShellVirtualDirectory –BasicAuthentication:$TRUE

Once changed Remote PowerShell works as expected.

Exchange 2013 Health Manager generating alerts in SCOM after reboot

We have a 26 server Exchange 2013 server environment, monitored by SCOM. Within Exchange 2013 Managed Availability is monitoring the health of the individual servers, and alerts are escalated to SCOM which sends out text messages to the Exchange administrators.

It is crucial to have this configured properly to avoid invalid or unneeded text messages being sent out.

I’ve noticed that after a reboot of an Exchange server Managed Availability can send out alerts, even when the probes and monitors involved have a global override. Using a global override Managed Availability should never send out alerts to SCOM anyways.

To avoid this from happening you can set the Managed Availability service on your Exchange 2013 server, which is the Health Manager service MSExchangeHM to “Automatic (Delayed Start)”.

The easiest way to do this is to use PowerShell using the Set-Service command:

Set-Service –ComputerName EXCH01 -Name MSExchangeHM –StartupType Type;

Where Type can be Disabled, Manual or Automatic.

Unfortunately it is not possible to set this to “Automatic (Delayed Start)” using PowerShell, but you can create a Registry key on the Exchange 2013 server to achieve this by using the Set-ItemProperty command:

Set-ItemProperty -Path “Registry::HKLM\System\CurrentControlSet\Services\MSExchangeHM” -Name “DelayedAutostart” -Value 1 -Type DWORD

To do this for all Exchange 2013 servers in your organization you can do something like this:

$ExServers = Get-ExchangeServer | Where {$_.Name –like “EXCH*”}
ForEach ($Server in $ExServers) {
  Write-Host “Setting Health Manager service on $Server to Automatic (Delayed Start)”
  Invoke-Command –ComputerName $Server {
    Set-ItemProperty -Path Registry::HKLM\System\CurrentControlSet\Services\MSExchangeHM -Name DelayedAutostart -Value 1 -Type DWORD
  }
}

MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled not available in CU9

You have Exchange 2013 CU9 running in your environment and you want to configure the option to store sent messages in the shared Mailbox instead of the user’s mailbox as described in my blogpost Exchange 2013, Shared Mailbox and Sent Items.

But when you open the Exchange Management Shell and try to change the Mailbox settings using the Set-Mailbox cmdlet, the options -MessageCopyForSentAsEnabled and -MessageCopyForSendOnBehalfEnabled are not available.

To solve this you can run the setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms command from the CU9 installation media.

But why wasn’t this run during installation of Exchange 2013 CU9 in the first place?

You might expect that when running the setup application (either using the GUI or using setup.exe /mode:upgrade) that the upgrade of the Active Directory Configuration partition automatically takes place.

However, this is not always the case. It turns out that when there are no Schema changes during the upgrade process, which is the case when upgrading from Exchange 2013 CU7 or CU8 to Exchange 2013 CU9, the preparation of the Configuration Partition in Active Directory is automatically skipped by the setup application.

This is a bit annoying and nothing will break (except the fact you’re missing some new functionality) and can be solved by running the Setup.exe /PrepareAD later on.

Exchange 2013, Shared Mailbox and Sent Items

When users are using shared mailboxes and send email messages out of this Mailbox, you want these messages to be stored in the shared Mailbox. This was already possible in Exchange 2010, but only starting in CU9 this is possible in Exchange 2013 as well.

It is a setting on the shared Mailbox and has to be set using the Exchange Management Shell and works for shared Mailboxes where both the Sent As permissions and Sent on Behalf of permissions are granted.

For shared Mailboxes with the Sent As permissions use the following command:

Set-Mailbox <mailbox> -MessageCopyForSentAsEnabled $True

For shared Mailboxes with the Sent On Behalf of permissions use the following command:

Set-Mailbox <mailbox> -MessageCopyForSendOnBehalfEnabled $True

image

When testing with Outlook (2013 in this case) and a shared Mailbox where Full Access and Sent As permissions are granted the email message that was sent is stored in the shared Mailbox.

image

A couple of remarks:

  • The email message is stored in the shared Mailbox, but a copy is stored in the user’s Mailbox as well.
  • This feature was already available in Office 365 (and can be set using Remote PowerShell).
  • If the –MessageCopyForSentAsEnabled and the –MessageCopyForSendOnBehalfEnabled are not available you should run the Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms in your environment to make the appropriate changes in the AD’s Configuration partition.

Exchange 2016 Public Preview

On July 22nd Microsoft released a public beta of Exchange Server 2016. Although the RTM version of Exchange Server 2016 is still quite some time in the future, this beta version will give you the possibility to have an early look at the software.

At first glance Exchange 2016 looks like some sort of Exchange 2013 SP3 and at some point I can agree (after all, there’s nothing wrong with Exchange 2013). Picture this, Microsoft has ten thousands of servers running Exchange 2013 in their datacenters, and when upgrading to a new version Microsoft simply cannot afford to add to much complexity when upgrading, like when upgrading from Exchange 2007 (BPOS in those days) to Exchange 2010, or from Exchange 2010 to Exchange 2013. From this perspective it makes sense there aren’t too much differences. But actually there are many, many new features in Exchange 2016 so it also makes sense to talk about a new version. And from a Microsoft support point of view they also have to release new versions (both major and minor) to keep track of supporting older versions…

In this blog post I’ll show some nice features and improvements, but there are many, many more to discover. Let’s go ahead and have a quick look…

Outlook on the Web (OOTW)

One of the most visible improvements in Exchange Server 2016 is the new user interface (UI) which now looks like the Office 365 OWA interface, but with several new improvements (which will follow later in Office 365) which makes the new UI very slick:

image

Figure 1. The new Converged OWA User Interface, now called Outlook on the Web (OOTW)

Continue reading Exchange 2016 Public Preview

Follow

Get every new post delivered to your Inbox.

Join 49 other followers