Thursday, October 11, 2018

Querying IP Addresses for EOP using PowerShell

There is always a desire to lock down the communication for Exchange hybrid servers. If you want to lock down a receive connector in your on-premises Exchange for communication with Exchange Online, there is a published list of IP addresses:
The only IP addresses on that web page that are relevant for a receive connector those for Exchange online and TCP port 25. These are the IP address for Exchange Online Protection (EOP).

To simplify automated configuration, Microsoft also makes these IP addresses available in XML format downloadable directly from Microsoft. You can download this using PowerShell.
[xml]$xml = invoke-webrequest -uri https://go.microsoft.com/fwlink/?LinkId=533185
Once you have downloaded the xml file, you can extract just the IP addresses for Exchange Online Protection.

$EopIP = (($xml.products.product | Where-Object name -eq "eop").addresslist | Where-Object type -eq "ipv4").address

Once you have that list of IP addresses, it's easy to configure a receive connector with that list of addresses.

Set-ReceiveConnector -Name O365 -RemoteIPRanges $EopIP



Wednesday, September 19, 2018

Unable to Enable MailUser

It's rare, but occasionally I run into a need to edit Exchange attributes on user mailboxes manually. Last week I had a situation where a user account had no Exchange mailbox, but did have some Exchange attributes populated.

This left me in a scenario where running Enable-MailUser failed for the user accounts. For some of the accounts, blanking out the HomeMDB attribute was sufficient. However, for two accounts, even after blanking out HomeMDB it didn't work.

When I ran Get-User (the Exchange cmdlet) it reported back that the account was already a MailUser. However, if I ran Get-MailUser I got an error back indicating that: "The operation couldn't be performed because object 'username' couldn't be found on 'servername'".

The fix for these two user accounts was to blank out the two additional attributes:
  • msExchRecipientDisplayType
  • msExchRecipientTypeDetails
Once those two attributes were cleared, I was able to use Enable-MailUser as expected.

Additional reading:

Monday, July 9, 2018

Hybrid Configuration Wizard not Starting

I think this is something to do with security permissions, but when I click a link to install the hybrid wizard all I see is a flicker scanning file and then nothing. I tried adding a few site to the trusted sites list.

You can download it directly here:
I'm putting the above link in my blog primarily so I remember where it is. I got this link from the following blog post.

Thursday, June 21, 2018

OneDrive Stops Syncing - Insider Preview

On my laptop, I run Windows 10 Pro Insider Preview current build 17692.1000. I am guessing that my OneDrive issue was related to that. It seemed to happen after a recent update, but I'm not 100% sure.

Here were my symptoms:
  • No errors presented in user interface (that is, I didn't know it was broken)
  • Worked on my laptop for a couple of days
  • Attempted to open file from my desktop and got old version
 Looking back at the laptop, I could see:
  • OneDrive icons in notification area were gone
  • Attempting to run OneDrive from the Start menu indicated that OneDrive.exe was missing.
  • OneDrive status was blank when viewing files in File Explorer.
 Some random searching came up with:
  • Modifying Group Policy settings to allow sync
    • Failed - because it wasn't even running!
  • Run OneDriveSetup.exe from C:\Windows\SysWOW64
    • Failed - error indicated a newer version was installed
  • Run OneDrive.exe from %LocalAppData%\Microsoft\OneDrive
    • Failed - file was not present
However, at this point, in %LocalAppData%\Microsoft\OneDrive, I saw there was a file OneDriveStandaloneUpdater.exe. I tried running that with no fix.

I browsed around a bit more and found OneDriveSetup.exe in the %LocalAppData%\Microsoft\OneDrive\Update folder. I ran this file and I got the dialog box indicating that OneDrive was being prepared for first use. When it completed, it kept the settings for both my personal and OneDrive for Business. The only hiccup was that the file I was working on over the last two days was listed as a conflict that I needed to resolve.

As much as this annoyed me, I think this shows how much better the OneDrive client is than it used to be. Not that long ago, almost any syncing problem was fixed by resyncing and downloading all of the data again. This properly recognized and retained a few GB of data only having an issue with the file that was modified while OneDrive wasn't running. That's pretty good.

Update June 26, 2018
Well this happened again, and I found an event log error that looks like the setup file for OneDrive was trying to run and failed. I was able to find this error for today and the previous event where it failed. Both were event ID 1001 which is pretty generic. The P5 value was different on the previous error.



 

I was able to confirm that running OneDriveSetup.exe alone was enough to fix the issue.

Thursday, May 31, 2018

Bye Bye FRS

As of build 1709 (that is September 2017), Windows Server 2016 does not support using FRS (File Replication Service) for the replication of SYSVOL data on domain controllers. Some of you are saying: "Man, that's old. Who uses that anymore?" Well, anyone that never bothered to update which is probably most small and even mid-sized businesses who have been updating to a new OS version over the years, but didn't realize they had a choice for SYSVOL replication.

The good news is that the update is really easy to do. The steps are as follows:
  1. Run dfsrmig /setglobalstate 1
  2. Wait until dfsrmig /getmigrationstate says all domain controllers have updated to state prepared
  3. Run dfsrmig /setglobalstate 2
  4. Wait until dfsrmig /getmigrationstate says all domain controllers have updated to state redirected
  5. Run dfsrmig /setglobalstate 3
  6. Wait until dfsrmig /getmigrationstate says all domain controllers have updated to state eliminated
A very nice writeup for this process with screenshots is located here:
Notification that Windows Server 2016 version 1709 no longer support FRS is here:

Wednesday, May 30, 2018

Expired Microsoft Exchange Server Auth Certificate

When you install your first Exchange Server 2013 or Exchange Server 2016 server, a certificate with the friendly name Microsoft Exchange Server Auth Certificate is created. This certificate is self-signed and used for OAuth authentication between applications such as Exchange Server and SharePoint. However, it is also used for hybrid deployments between on-premises Exchange Server and Exchange Online.

This certificate is unique because it is installed on all of your Exchange servers. The subject for the certificate is "CN=Microsoft Exchange Server Auth Certificate" and does not contain any SAN names with references to specific servers.

It also has a 5-year lifetime. Which is just long enough for everyone to forget about it. I suspect that this certificate is due to expire in many organizations soon.


Today I got a call from an organization with the following symptoms:
  • Outlook clients were slow to start
  • Outlook clients were not displaying the user's calendar
  • Outlook clients were not able to access Out-of-Office settings
  • Everything was functioning fine the previous day
  • No system changes had been made
  • The organization is configured in hybrid mode with Exchange Online, but the issue was occurring for on-premises users
  • Accessing through OWA was unaffected
An initial review of the configuration didn't identify anything out of the ordinary except that the Microsoft Exchange Server Auth Certificate had expired about two weeks ago. There was also this related event in the Application log:


The event information is:

Source: MSExchange Web Services
Event ID: 24

The Exchange certificate [Subject]
CN=Microsoft Exchange Server Auth Certificate

[Issuer]
CN=Microsoft Exchange Server Auth Certificate

[Serial Number]
3329C02443B435A447B92E81EB177303

[Not Before]
2013-06-11 6:25:31 PM

[Not After]
2018-05-16 6:25:31 PM

[Thumbprint]
DFC06BF3FC76974BCD1C050340998B65D5491007
expired on 2018-05-16 6:25:31 PM.
This certificate is not bound to IIS, so why is this expiration being noted by MSExchange Web Services?

The certificate used for authorization is set separately from IIS but is configurable. You can see the currently configured certificate by using Get-AuthConfig. The thumbprint for the certificate is listed in the CurrentCertificateThumbprint property.


If you've already been searching around related to this certificate, you've probably found some instructions on how to recreate it. However, if it is expired, you can just renew it instead by using the Exchange Admin Console. In servers > certificates, select Microsoft Exchange Server Auth Certificate and then click Renew in the details pane as shown below. The screen shot below is of a certificate that is not expired yet, it looks exactly the same other than the expiry date.

Renewing creates a second certificate named Microsoft Exchange Server Auth Certificate that is valid for another 5 years. This certificate has a new thumbprint and exists only on the server you've renewed it on. You need to identify the thumbprint for the new certificate. If you edit the certificate, in Exchange Admin Center, the thumbprint is on the general tab as shown below. You can type this in, but you're probably better of to cut and paste it into the later commands.





My preference is to put the required information for the next command into variable. We need the thumbprint of the new certificate and the current date.

$thumb = "NewCertificateThumbprint"
$date = get-date

Then run the following command to add the new certificate:

Set-AuthConfig -NewCertificateThumbprint $thumb -NewCertificateEffectiveDate $date


You will get a warning that the new effective date is not 48 hours in the future. However, if we're recovering from an expired certificate, we're OK with that.

Now you need to publish the certificate to all servers:

Set-AuthConfig -PublishCertificate


And finally, remove the old expired certificate from the configuration:

Set-AuthConfig -ClearPreviousCertificate





Finally, since we've removed all references to the expired certificate you can delete it from all Exchange servers.

You may find that you need to do an iisreset after all of the AuthConfig changes were done. I found some examples where they ran iisreset.exe and didn't take the time to experiment. It's possible that it will pickup without a restart but just take longer.


If you are renewing the certificate before expiry then the process is much simpler:
  1. Renew the certificate (no new certificate is created)
  2. Publish the certificate.




Tuesday, May 29, 2018

Windows Update 0x800705b4 (Windows Server 2016)

While setting up a new server running Windows Server 2016, I had the install of the latest cumulative update (May 2018) failing with error code 0x800705b4.

When I searched about this error there were a lot of articles describing how to reset Windows Update and potentially solve this issue. Most of those pertained to Windows 10.

For Windows Server 2016, I found a quick and easy solution. Download and install the update by using sconfig instead. Apparently sconfig uses a different process for installing updates than the graphical interface.

First, open a PowerShell prompt or command prompt as Administrator:


Select Option 6 to download and install updates. This opens another window:


Select whether you want to list all updates or just recommended updates. And then select which updates you want to install. After installation, you'll be prompted to restart just like the standard update process.