Saturday, December 10, 2016

Kemp Load Balancer: Change from One-Arm to a Two-Arm Configuration

During the planning and set up phase of my current Exchange 2016 project, management stipulated that no external Exchange access was to be allowed - less pain for me!
Several months later after the environment is in production, they now want to allow external access...go figure :)

There were several issues here: we have a one-arm Kemp virtual load balancer installed on the internal LAN; the firewall/security team didn't want to NAT anything internally (they will only NAT to the DMZ); NATing to the DMZ requires another load balancer (costing more money) or a reverse proxy solution, which would then have to redirect back to the internal Kemp...not a graceful solution.

I decided that it would save a ton of trouble just switching the existing Kemp from a one-arm config to a two-arm.
Meaning, it will have one NIC in the internal LAN, and one NIC in the DMZ thereby allowing both internal and external client connections.

The steps are pretty straightforward and some of the things will be specific to your environment.

**Disclaimer** You should not perform this on a production environment as it can result in loss of client connections...but if you have no choice, go for it!

**Note** You should take a back up the current config before starting the changes.

**Note** You will have to restart the load balancer during the changes, so it's best to do this outside business hours.

Changing a One-Arm Kemp LoadMaster to a Two-Arm Configuration:

First, you'll need to add a second NIC to your load balancer VM and assign it to another network, such as your DMZ.

In my case, I already had two NICs defined (eth0 and eth1) but eth1 wasn't being used, so I set the DMZ network on that one.

My initial setup was eth0 on the internal 10.x.69.x network, which allowed on internal connections.

Kemp eth01

Now, I've added the DMZ network to eth1, which is on the 10.x.68.x network.

Kemp eth1

In our network, the DMZ isn't routable back to internal, so we need to do some extra configuration on the Kemp itself.

We'll need to ensure that we don't have asymmetric back end routes, which occurs in two-arm setups, by enabling "Subnet Originating Requests". We'll also need to "Enable Non-local real Servers".

Both of the above settings are found in Systems Configuration > Miscellaneous Options > Network Options.

Put a checkmark for both Subnet Originating Requests and Enable Non-local real Servers

Kemp Enable Non-local and Subnet Originating

Next, we'll need to configure the WUI (Web User Interface) to be reachable from the internal NIC.

Navigate to Certificates > Security > Remote Access

Here, next to "Allow Web Admin Access" we'll use the drop-down box to select our Internal NIC, which on my system is eth0.

We'll then set the "Admin Default Gateway" to our Internal LAN Gateway on the 10.x.69.x subnet; this ensure we can still get to the WUI once we change our routes later.

Kemp WUI Admin Access

Next we'll need to set the Default Gateway to the DMZ network, since our DMZ is not routable to the internal LAN.

**Note** This step requires console access because once you change your default gateway, you will lose WUI access. You will also need to reboot your device after changing the gateway - this will be from the console.

**Note** The Default Gateway is a global setting, there isn't an option for setting it on each NIC.

Navigate to System Configuration > Default Gateway

Here, we'll set it to your DMZ Gateway, in my case this is my 10.x.68.x subnet.
Kemp Default Gateway

In your console, login to the load balancer, and select option 8 - reboot.

Now, the last step is creating our new Virtual Services (VS) and Virtual IP Address (VIP) on the DMZ interface. This is done exactly like you configured your internal VIP and VS, by using the Exchange templates and existing Exchange cert.

Go to Virtual Services > Add New

Assign your Virtual Address (VIP) which will be on your DMZ subnet.

Give it a Service Name.

I added the word "external"- this is not optional when adding another VS using the same template, because it will automatically try to use the same service name as the already configured internal VS and they cannot be the same.

In the Use Template drop-down, select Exchange 2016 HTTPS Reencrypted...the port will magically change to 443.

Click "Add this Virtual Service"

Kemp Add New Virtual Service

Go to Virtual Services > View/Modify Services, you should now see your second VS on the DMZ VIP.

In my example, my DMZ Virtual Services are on the VIP and my Internal VS are on the VIP.

Kemp Internal/External Services

Now we need to configure the new DMZ SubVS just like you did for you internal Virtual Services, and then assign your Exchange Certificate.

If you need a refresher on how to configure those SubVS and certs, follow Gareth Gudger's (SuperTekBoy) awesome post here; you'll just be doing the same steps on the newly created DMZ Virtual Services.

Once you finish those settings, you're ready to test!

From an external machine try to hit your OWA, set up Outlook, and ActiveSync on your device...if your NATing and firewall rules are set correctly you should have no problems with external access.

Now to get less sleep since you can check email from anywhere!

Saturday, December 3, 2016

Exchange 2016 Management Shell Won't Connect Error: The WinRM Shell client cannot process the request

The other day after patching and bouncing my Exchange 2016 servers, one of them came back up pretty grumpy.
All services were running, and mailflow was healthy, but the Exchange Management Shell (EMS) threw WinRm errors when opening.
The Application and System Event Logs were full of warnings and errors too.

Luckily the event logs are little more helpful, because the error thrown in the EMS didn't really tell me what was actually going on.

EMS Error:

Connecting to EXCHMBX01.exchangeitup.com.
 New-PSSession : [EXCHMBX01.exchangeitup.com] Processing data from remote server EXCHMBX01.exchangeitup.com failed
 with the following error message: The WinRM Shell client cannot process the request. The shell handle passed to the WSMan Shell function is not valid. The shell handle is valid only when WSManCreateShell function completes successfully. Change the request including a valid shell handle and try again. For more information, see the about_Remote_Troubleshooting Help topic.

As you can see, processing data failed...WinRM...ok what does that mean? After it throws the error, the Shell will remote session over to another Exchange server, so at least you're not dead in the water.

Event Logs:

Log Name:      Application
Source:        MSExchange Front End HTTP Proxy
Date:          11/28/2016 10:16:41 PM
Event ID:      1003
Task Category: Core
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EXCHMBX01
[PowerShell] An internal server error occurred. The unhandled exception was: System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.Exchange.HttpProxy.RemotePowerShellProxyRequestHandler.ExposeExceptionToClientResponse(Exception ex)
   at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CompleteWithError(Exception ex, String label)
   at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass29.b__28()
   at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)

Log Name:      Application
Source:        ASP.NET 4.0.30319.0
Date:          11/28/2016 10:16:40 PM
Event ID:      1309
Task Category: Web Event
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      EXCHMBX01
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 11/28/2016 10:16:40 PM
Event time (UTC): 11/29/2016 3:16:40 AM
Event ID: 90a2cfed15c84e1ab33affbe5cb62d96
Event sequence: 2
Event occurrence: 1
Event detail code: 0

Application information:
    Application domain: /LM/W3SVC/1/ROOT/PowerShell-1-131248629080807714
    Trust level: Full
    Application Virtual Path: /PowerShell
    Application Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell\
    Machine name: EXCHMBX01

Process information:
    Process ID: 9212
    Process name: w3wp.exe
    Account name: NT AUTHORITY\SYSTEM

Exception information:
    Exception type: NullReferenceException
    Exception message: Object reference not set to an instance of an object.
   at Microsoft.Exchange.HttpProxy.RemotePowerShellProxyRequestHandler.ExposeExceptionToClientResponse(Exception ex)
   at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CompleteWithError(Exception ex, String label)
   at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass29.b__28()
   at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
   at Microsoft.Exchange.HttpProxy.Diagnostics.SendWatsonReportOnUnhandledException(Action methodDelegate, LastChanceExceptionHandler exceptionHandler)
   at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(Action method)

Log Name:      System
Source:        Microsoft-Windows-HttpEvent
Date:          11/28/2016 10:25:39 PM
Event ID:      15021
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EXCHMBX01
An error occurred while using SSL configuration for endpoint  The error status code is contained within the returned data.

From the above logs, we finally see that there's something wrong with the HTTP/SSL config on the PowerShell virtual directory.

The Fix:

Close the Exchange Management Shell.

Open IIS Manager, and drill down to Servername > Sites. Right-click Exchange Back End and select Edit Bindings.

IIS Edit Bindings

In the Site Binding window, select the HTTPS binding, and click Edit.

Under SSL Certificate, it will say Not Selected - meaning there's no certificate assigned to the HTTPS service on port 444, which was referenced in the System log Event 15021.

Click the drop-down and select your applicable certificate - this will usually the self-signed cert, but you can check your other working servers to see which one is assigned.

IIS Assign Cert

Click OK

Fire up the EMS and you should have a successful connection!

Saturday, November 26, 2016

Exchange 2013/2016 Cleaning up old Diagnostic and IIS Log Files

A while back I cross-posted an article by Jason Sherry on cleaning up Exchange 2013 Log files with a one-liner.
Jason's solution worked very well, until I stood up a new Exchange 2016 environment, and it just wouldn't run - no errors, it just didn't do anything.
So, I came up with a scheduled task that works awesome, and keeps those pesky logs file down to a manageable size.

A little back story:
Exchange 2013/2016 keeps pretty much every diagnostic log in order for MS Support to easily go back and find problems without having to wait for Exchange admins to manually pull logs. The problem is: Exchange does a very poor job of cleaning up said logs and they fill up your system volume very quickly.

I know, I know, disks are cheap - well businesses are cheap too, and won't always pay for what you need!

Creating the "Clean Logs" Scheduled Task:

The following task will clean up the Exchange Daily Performance Logs and IIS logs keeping only the past 3 days.

Create a Service Account:

First, you'll want to create a Service Account in your domain, which will be used to run the scheduled task. It's best practice to use service accounts rather than your own account to run scheduled tasks, so if you ever leave your position and they deactivate your account, it won't break the task!

In your domain, create a new user called something like exchscriptrunner and set a super-strong password.
The only membership it needs is Domain User, so it should be good to go.

Next, add the newly created user to the Local Administrators Group on each Exchange server. The scheduled task will need local admin rights to run PowerShell things, and since you have a super strong password, it's not an issue.

Create the scheduled task on the first Exchange server:
On one of the Exchange servers in the Task Scheduler Control Panel, click Action > Create Task...

On the General tab:

Give it a name like Clean Logs

Click "Change User or Group..." hit "Locations" and switch to your domain, then search for your exchscriptrunner service account.

Check the box for "Run with highest privileges"

On the Triggers Tab:

Click "New..."
Set it for how often you need it to clean up the logs. I run mine Daily at 10AM - no specific reason, but you do want it to run Daily. You can run It during production hours as it doesn't use many resources.


On the Actions Tab:

Set the "Action" dropdown to "Start a program"

Under Program/Script, copy/paste the following:


In the "Add arguments" field, copy/paste the following:

-NonInteractive -WindowStyle Hidden -command ". 'C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; Get-ChildItem 'C:\Program Files\Microsoft\Exchange Server\V15\Logging','C:\Inetpub\Logs' -Directory | Get-ChildItem -Include '*.log','*.blg' -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-3) | Remove-Item -ErrorAction silentlycontinue

**Note** This assumes that you have installed Exchange to the default location. If you have installed it to another location, change the "C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1" and "C:\Program Files\Microsoft\Exchange Server\V15\Logging','C:\Inetpub\Logs" to match your environment.

**Note** This keeps the last 3 days of logs, which should be sufficient for any error intel gathering...if 3 days have gone by and you haven't noticed problems in Exchange, you might need some monitoring :)
To change it to more or less than 3 days, set the "AddDays(-3)" to a different number value.


In the Settings Tab:

Checkmark the following boxes:

- Allow task to be run on demand

- Stop the task if it runs longer than: 1 hour (if it runs longer than an hour, you got something wrong!)

- If the running task does not end when requested, force it to stop


Click OK when you have everything set.

Testing the Clean Logs Task:

In the main task window, right-click your new "Clean Logs" task, and click Run.

When it finishes running, you should have a (0x1) Last Run Result.

You can also go check C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics\DailyPerformanceLogs (or wherever you've installed Exchange) and you should see only three days' worth of log files.

Create the scheduled task on the other Exchange servers:

Once you've successfully run the task, you'll need to create it on your other Exchange servers...this is super easy!

In the main Task Scheduler window, right-click your "Clean logs" task and click "Export" and save the file to your preferred location.

This will create an .xml file with all the settings intact.

Copy the Clean logs.xml file to each of your other Exchange servers. 

On each Exchange server, open the Task Scheduler.

Click the Task Scheduler Library folder in the left pane.

Click Action, and "Import Task..."

Select your Clean logs.xml file and hit Ok.

Now you'll see the Clean logs task at the ready state in the Task Library on each server.


To supplement the scheduled task, if you have rather small Exchange install volumes, I also like to compress the C:\Program Files\Microsoft\Exchange Server\V15\Logging directory - with zero adverse effects. To do that,
follow my post here.

Now, with this scheduled task and a compressed logging directory, you should save tons of space on your servers, and be free from filling up the drive causing mailflow to fail ;)

Thursday, November 24, 2016

Exchange PowerShell Cmdlets Repository - Updated

A loooong time ago I wrote a post on useful Exchange Shell cmdlets.
As the years have gone by I have cleaned up some old commands, and added new ones.

This is a folder shared out on my Google Drive, containing a broad range of commands, which you can download and copy paste them into the EMS (Exchange Management Shell).

Here's a listing of the commands:

Exchange - Add Full Access Without AutoMap.txt
Exchange - Block ActiveSync By Device ID.txt
Exchange - Bulk Add Public Folder Permissions.txt
Exchange - Bulk Convert User Mailbox To Shared.txt
Exchange - Bulk Create Contacts From CSV.txt
Exchange - Bulk Create Distribution Groups From CSV.txt
Exchange - Bulk Create Linked Mailboxes.txt
Exchange - Bulk Delete Messages from User Mailboxes.txt
Exchange - Bulk Remove Distribution Groups From CSV.txt
Exchange - Bulk Remove Mailbox Permissions from All Mailboxes.txt
Exchange - Bulk Remove User Mailboxes From CSV.txt
Exchange - Bulk Set Archive Quota.txt
Exchange - Check Build and Rollup Numbers.txt
Exchange - Check Database Backup Status.txt
Exchange - Clear Disconnected Mailboxes.txt
Exchange - Clear Export Import Move Requests.txt
Exchange - Clear Move Request.txt
Exchange - Convert User Mailbox To Other Type.txt
Exchange - Copy Receive Connectors.txt
Exchange - Create and Connect a Mailbox to User.txt
Exchange - Create Linked mailbox.txt
Exchange - Create Shared Mailbox.txt
Exchange - DagHealth.txt
Exchange - Disable User Mailbox.txt
Exchange - Distribution Group Member Count.txt
Exchange - Distribution Group Owners Report.txt
Exchange - Dynamic Distribution Group Member Count.txt
Exchange - Environment Report HTML.txt
Exchange - Export All Email Addresses.txt
Exchange - Export List of Alias and Displayname from a CSV.txt
Exchange - Force a GAL Update.txt
Exchange - Get All Databases Size With WhiteSpace.txt
Exchange - Get All Databases Size.txt
Exchange - Get All Dynamic Distribution Group Filters.txt
Exchange - Get Distribution Group Members.txt
Exchange - Get Distribution Groups With No Members.txt
Exchange - Get Folder Count In a Mailbox.txt
Exchange - Get List of Aliases from Display Names.txt
Exchange - Get List of Aliases From Full Names.txt
Exchange - Get List of Full Access Permissions.txt
Exchange - Get List of IP Relays.txt
Exchange - Get list of Largest Mailboxes.txt
Exchange - Get List of Mailboxes by OU.txt
Exchange - Get List of Members in Dynamic Distribution List.txt
Exchange - Get List of Messages Sent From a Domain.txt
Exchange - Get List of Resource Mailboxes.txt
Exchange - Get List of Room Mailboxes.txt
Exchange - Get List of SMTP Addresses by OU.txt
Exchange - Get Mailbox Count On Each Database.txt
Exchange - Get Mailbox Folder Sizes For User.txt
Exchange - Get Mailbox Quotas Not Set to Default.txt
Exchange - Get Mailbox Quotas.txt
Exchange - Get Mailbox Size For an OU.txt
Exchange - Get Mailbox Stastics On Each Server.txt
Exchange - Get Mailboxes With Forwarding Set.txt
Exchange - Get Outlook for iOS and Android Users.txt
Exchange - Get Public Folder Database Report.txt
Exchange - Mailbox and Archive Move To Other Databases.txt
Exchange - Mailbox Export.txt
Exchange - Mailbox Import.txt
Exchange - Move Public Folders to New Mailbox.txt
Exchange - Recall Emails.txt
Exchange - Recover Items From Mailbox Dumpster.txt
Exchange - Redistribute Databases Across DAG.txt
Exchange - Remove Database and DB Copy.txt
Exchange - Remove Mailbox Forwarding By OU.txt
Exchange - Remove Virus from Mailboxes.txt
Exchange - Set SingleItemRecovery On All Mailboxes.txt
Exchange - Show Deleted Mailboxes in DB's in the EAC.txt
Exchange - Test Health of Servers.txt
Exchange - View Export Request Statistics.txt
Exchange - View Mailbox Size List.txt
Exchange - View Move Request Statistics.txt

Link: Exchange PowerShell Commands.zip

**Note** Its on Google Drive and you can choose individual files to download, or hit CTRL+S to get the whole archive.

Friday, October 28, 2016

Exchange 2016 Distribution Group Owners Can't Edit Members In Resource Forest

In my Exchange 2016 Resource Forest, for some reason Distribution Group Owners could not add or remove members of those groups from within Outlook.

They would get the following error:

"Changes to the public group membership cannot be saved. You do not have sufficient permissions to perform this operation on this object."

Outlook Ditstro Change Error

Real descriptive error

We tried several different things such as:

Enable AD Full Control permissions for the owner - didn't work
Enable AD "Manager can update membership list" - didn't work
Enable AD "Write Members" - didn't work

Finally what did work (and is totally counterintuitive as I'll show later) was enabling the "Distribution group memberships" setting in the Default Role Assignment Policy.

In the EAC, navigate to permissions > user roles

Double-click the Default Role Assignment Policy

**Note** If you have created other role assignment policies, you'd choose that one

In the Policy mark the checkbox for "Distribution group memberships"

Default Role Assignment Policy

Give it some time for replication and check that owners can edit their distro group memberships from Outlook.

**Note** They might have to close and reopen Outlook for changes to take effect.

The counterintuitive part: even though we enabled a setting that says "the role enables users to view and modify their membership in groups" it actually does not allow them to do so...bug? I dunno, but Exchange 2016 is filled with 'em.

Tuesday, October 11, 2016

Outlook 2016 Autodiscover for Non-Domain Joined Computers

Outlook 2016 requires Autodiscover to connect to Exchange, which can make it difficult for users on non-domain joined PCs.

Meaning: unlike previous versions of Outlook, there is no manual setup for Exchange accounts.

If some of your users have personal machines that they use to connect to Exchange, there's a registry fix (hack), that will bypass that domain check and allow them to configure their Outlook profile.

First, download the Outlook2016.reg key file from my
Google Drive.

**Note** You can also create the reg key manually:

Open Notepad, and paste the following into it:

Windows Registry Editor Version 5.00



Close and Save the file as Outlook2016.reg

Once you have downloaded or created the registry key, we'll need to import it.

Simply double-click Outlook2016.reg

Click Yes that you are sure you want to continue.

Click Ok.

Now try to set up your Outlook profile to connect to your Exchange environment.

Friday, October 7, 2016

Exchange 2013 Filtering Management and Transport Service Won't Start

I've seen this issue crop up from time to time on Exchange 2013 builds, where you get an error for the Microsoft Filtering Management Service which throws an 80004005, which also causes the Microsoft Exchange Transport Service to throw a 1068 error.

The Filtering Service is the Exchange protection/antimalware scanning component and it's a dependency of the Transport Service.

What usually causes this is a misconfigured A/V solution that doesn't have the proper Exchange exclusions set, and it rips out a needed file.

**Note** Follow this not-so-short MS article to set those A/V exclusions.

There's a couple ways to go about fixing the issue, but I'll show you the easiest.

Here's the errors you'll likely see:

MS Filtering Service Error
Transport Service Error

First, search in the Event Viewer > Application Logs for an error stating that the ConfigurationServer.xml file is missing.

If so, we'll need to add that file back in.

Mount or open the Exchange Cumulative Update setup file that matches the current build you're running on your Exchange servers.

**Tip** Always keep your most recent CU files, because things like this happen *cough* often *cough* with recent versions of Exchange - test much, Microsoft?

Once you have your CU setup files open, browse to the Setup\Filtering directory, and you'll see the "ConfigurationServer.xml" file in there.

Copy the "ConfigurationServer.xml" file to "C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data" on your Exchange server.

**Note** You can copy that file from a working Exchange server, but it involves many more steps such as disabling the malware scanning, rebooting, disabling services, renaming files, blah blah...my way is faster.

Now that you've copied over the missing file from the CU setup, you should be able to:

Start the Filtering Service

Start the Transport Service

**Note** You may have to reboot before you're able to start those services.

Now you should have a healthy Exchange server...go check those A/V exclusions!

Thursday, September 22, 2016

Exchange 2016 Adding Custom Fields to Outlook Contact Cards

In my current project, we have a need to add certain fields to Outlook contact cards such as Employee ID number, Location Code, and the like.

These fields are controlled by the Address List, and to make changes to them, you use the Details Template Editor in the Exchange Toolbox.

With the editor you can: change field sizes, add/remove fields, add/remove tabs, rearrange the layout, and more to suit your needs. Once you're done, all changes will presented in the users' clients.

In the Exchange Toolbox, double-click the Detail Templates Editor


We'll be editing the details for English Users, so scroll down and double-click the en-US\User template

It will open the default settings

First, we'll need more real estate to work in, so drag the bottom re-sizer bar to make the are larger.

Next we'll be adding a new Listbox.

The easiest way to add a listbox and keep the correct formatting is to copy one of the default boxes.

Right-click one of the default boxes and click Copy

Next right-click anywhere in the empty space below the default boxes and click Paste

Now we can position the listbox.

Drag the new listbox to the location that you want. Blue guide bars will appear telling you that it is in line with the other boxes.

You can also manually position the box by editing the x/y axis and height/width in the left editor pane

Tip: Click the default box above the newly created one and look at its height/width and X axis settings. Edit the height, width, and X axis of the new box to match. In our case it will be height: 12; width: 100; X axis: 82

**Note** MS TechNet says there is no undo and that you have to delete and start over, but that's wrong. You can CTRL-Z to revert to your last step.

Now, we'll add a Label to the listbox by selecting Label in the left pane, and dragging it next to the new Listbox

Next, name the label. In my example, this will be an Employee ID box, so we'll edit the label in the right editor pane

Now we need to link the Listbox to an attribute. As you can see, if you click on a default box, and check the right pane, you'll see the attribute that the box is pulling data from. Here, the attribute for the Phone field is called Telephone-number.

Since our new Listbox is for the Employee ID number, we'll map that attribute by selecting the new box, and in the right pane, use the drop-down to find Employee-Number

**Note** You can set all kinds of attributes on the boxes, including the Exchange Custom Attributes 1-15, or as we do in my environment Attributes 16-30 that were imported from MIM :)

Once you're satisfied with your new Listbox, click File > Save in order for changes to take effect

Now, give it time for the address list to replicate the changes then close and reopen Outlook and you should see the newly created field in the contact card

If you are unhappy with the results, you can go back into the editor and make changes, then save again and then new changes will be applied.

If you need to revert back to the default template just follow these simple steps:

In the Details Template Editor, select the template you changed (en-US\User) and in the right pane, click Restore. Click Yes. Now your template will be back to the original state.

Friday, September 2, 2016

Exchange 2016 Removing a DAG Network

In my project of setting up a greenfield Exchange 2016 environment, our project managers kind of jumped the gun on forcing us to install Exchange before we acquired a shiny new VM infrastructure - seems like that happens quite a bit huh?

This resulted in me having to stand up Exchange on our current/old VM environment, which was painfully slow, and Exchange didn't exactly perform well. I also had to configure separate DAG networks, one for MAPI and one for Replication since the networking was rather slow; Exchange 2016 Preferred Architecture advises to use only one NIC for both types of traffic - providing you have the infrastructure for it!

When we were finally able to get the new gear with 10GB networking, we now had to migrate those Exchange servers over; the problem was the Replication LAN was non-routable and couldn't be moved to the new VM infrastructure.

So, now I had to deal with removing the Replication DAG Network, which if you've ever done this, you've probably noticed that when you remove it, it comes back automatically because the Cluster still sees it.
The MS TechNet article on removing the DAG Network says nothing of this, it just gives you the cmdlet, which doesn't work anyhow because you'll get an error saying that you need to assign the active subnets to other networks...huh?

Here's how I finally removed the Replication DAG Network, with what did and didn't work:

What Didn't Work:

In our setup, we have two NIC's; one for MAPI, one for Replication:

First, I tried to remove the network, by clicking the "Remove" link in the EAC under Servers > Database Availability Groups > DAG Network > ReplicationDagNetwork01:

This threw an error saying to use the -IgnoreNetwork cmdlet instead, which is fine but it still leaves the network there, which isn't gonna work properly later when we migrate the VM's:

Next, I tried deleting the subnet from the Replication Network, which resulted in the cluster creating another network automatically:

Great, now we have an extra DAG network, and it has reassigned the subnet and NICs and has replication enabled.

Go ahead and Remove the first Replication network (the one without the subnet) to get us back to two networks again:

What Did work:

On each DAG node, I deleted the Replication NIC, so I'm left with just the MAPI NIC:

Give it a few minutes, and Exchange will show that the Replication DAG Network is misconfigured:

**Note** In most cases "misconfigured" is bad, but in this case we want it that way, so we can remove the network.

Now, that it's misconfigured, your can remove the subnet by clicking "View Details" on the DAG Network and hitting the minus sign "-" under Subnets:

And then remove the DAG Network itself:

Now we have one DAG Network:

Now we're where we need to be with one DAG Network for both MAPI and Replication running nicely on the 10GB LAN!

Sunday, August 28, 2016

Exchange 2013/2016 Using The Exchange Management Shell Through A Web Proxy

In my current project, we have Exchange 2016 running in a pretty secure environment consisting of a Resource Forest, and all servers are behind a HTTP Proxy Server.

Having Exchange behind a proxy can cause all sorts of headaches including not being able to download CU .iso files, FIPS (anti-malware) update failures, Remote PowerShell connection problems, and Federated Sharing issues.

The best course of action is to get your security team to allow Exchange out through the proxy, or at the very least disable authentication requirements...but sometimes that's not an option, so I'll show you the next best option.

Most likely, you'll have your Web Proxy configured in Internet Explorer, and you can use PowerShell to import those settings into the Exchange Management Shell (EMS).

**Note** Importing the proxy settings only works with explicit proxy settings in IE, it cannot use a PAC script.

**Note** Since Exchange 2013/2016 runs a web-based EAC (Exchange Admin Console), you really only need to set exclusions in the proxy for local addresses, and that should allow all connections to the EAC.

On each Exchange server do the following:

First, fire up an elevated Windows PowerShell to ensure that you have your exclusions set, by running:

netsh winhttp set proxy ";*.exchangeitup.com;*.exchangeitup.org;*.exchangeitup.net"

**Note** Change "" to your proxy server IP address, and whatever domain names you need to exclude for instance "exchangeitup".

Next, import the proxy into PowerShell by running:

netsh winhttp import proxy source=ie

**Note** IE proxy settings are set per user, not per computer so you'll need to import them on each admin account that logs into the Exchange servers. Or you can set it through a GPO, but I try to keep GPO's on Exchange servers to a minimum :)

Next, add your proxy server authentication to the Credential Manager under Control Panel.

Next, we'll add the proxy to the EMS on each Exchange server, by running:

Set-ExchangeServer -identity EXCH01 -internetwebproxy:
Set-ExchangeServer -identity EXCH02 -internetwebproxy:
Set-ExchangeServer -identity EXCH03 -internetwebproxy:

**Note** Change the server name and proxy IP to match your environment.

You can verify that the proxy is set on each server by running:

Get-ExchangeServer |fl name,internetwebproxy

Now you shouldn't be blocked by your proxy when trying to do everyday Exchange management, but like I said above best is to allow Exchange out to the internet "uninhibited" to alleviate all the headaches :)

Wednesday, July 27, 2016

Exchange 2016 Installing Exchange In A Resource Forest: Part 4

This is a continuation from Part 3 of my Installing Exchange 2016 in a Resource Forest series.

I've also created this guide as an eBook. Click the following links for each format:

Request and Import a new UC certificate

Generate the Cert Request (CSR)

1.      On one Mailbox Server, open the Exchange Admin Center (EAC) and navigate to Servers > Certificates.
       2.      Hit “+” button
       3.      Choose to create a request for a certificate from a certification authority
       4.      Enter a friendly name for the cert (can be anything you want). You’ll see this name in the list of certificates installed on the server, so make it something that you will easily recognize; maybe call your new certificate something like “Exchange 2016 UC Cert”.

Although you can technically use a Wildcard cert, don’t select Wildcard – it makes things painful later on.

5.      Choose a server to store the cert request on. This server will be used to complete the request, and will be the first server that has the certificate installed.
       6.      Now, just hit “Next” because we’ll select the SSL names on the next screen.
       7.      At the next step you can select and remove any unwanted names, edit existing names, or add more names to the certificate request.

The most important ones we need will be:


**Note** The server name will be present, and won’t hurt anything. You’ll also need to add any extra domains you will be using. For instance us.domain.com or domain.org.

You will need to pay for each additional domain name, but it depends on your provider, so it’s best to only include the ones you need.

8.      Enter your Organization info.
       9.      Enter a UNC path to save the request on: \\EXCH-MBX-01\c$\temp\exchcert.req
       10.  Click Finish and submit that .req to your Certificate Authority like DigiCert or GoDaddy.

Complete the Pending Cert Request

1.      Download the cert file provided from your CA to C:\Temp
       2.      In the EAC, go to Servers > Certificates
       3.      Click the Pending Request, and in the right-hand pane, click Complete near the bottom.
       4.      Enter the UNC for the cert file: \\EXCH-MBX-01\c$\temp\newcert.cer

If successful, it will show as “Valid”.

Assign the Cert to Services

Once your cert is installed, you can assign it to Exchange services such as IIS, SMTP, etc.

1.      Still in Servers > Certificates, select the new SSL cert, and click the “Pencil” button.
       2.      Check every box that you need – most times you’ll need IIS, SMTP, POP, IMAP. If you run UM, check those too.
       3.      Click “Save”.
       4.      You will be prompted to overwrite the existing SMTP service, click “Yes”.

Configure Outlook Anywhere

1.      In the EAC, go to Servers, and double-click your first server.
       2.      Choose Outlook Anywhere.
       3.      Set your namespace for Internal and External host names to match your namespaces you used in the Set Namespace section i.e. Mail.domain.com
       4.      And set NTLM for the auth method.

Import certificates on the Load Balancer

Each Load Balancer is different, but for Kemp follow these steps:

1.      Export your certificate from Exchange.

On the Load Balancer:
       2.      Go to Virtual Services > View/Modify Services.
       3.      Click the Add New button under the Certificate Installed Column.
       4.      Click Import Certificate in the upper-right, then next to Certificate File, click Browse.
       5. Select your .pfx file that you exported from Exchange, input the passphrase, and specify the cert name: Exchange 2016 UC Cert
       6.      Click “Save
       7.      On the Cert Config screen, select the VIP in the “Available VSs” and hit the right arrow to move it to the Assigned VSs box.
       8.     Save Changes
       9.      Now back at the View/Modify Services page, you can see the cert is assigned to the VIP.

Now test your pings and nslookups to ensure that mail and autodiscover resolve to the LB and open OWA and Outlook to ensure you don’t get any cert prompts.
All Done!

You should now have your Exchange Resource Forest set up and functioning behind your Load Balancer, with mail flowing in and out through your Edge server.

Now create some linked mailboxes by following my previous post: