Exchange 2016 Export Mailbox Error: "Couldn't find the Enterprise Organization container"

I've been running Exchange 2016 environment for a little while now, but I finally had to export a mailbox to PST.

I kept getting an error in both the EAC (Exchange Admin Console) and the Shell.

The error:

New-MailboxExportRequest -Mailbox "staceybranham" -FilePath \\server1\PSTs\stacey.pst

Couldn't find the Enterprise Organization container

This error is usually thrown when you haven't added your admin account to be allowed to import/export mailboxes.

The "funny" thing is: I had already run the following cmdlet to do so:

New-ManagementRoleAssignment -Role "Mailbox Import Export" -User Admin

But, every time I ran the export it would error out.

What I forgot to do, was close and reopen both the EMS (Exchange Management Shell) and the EAC.

After that, I was able to run the export without the error.
By the way this is a stupid error since the Enterprise Organization Container obviously exists, or there'd be no Exchange.

How about next time just have it say "you don't have a Management Role set for this account" or something to that effect? It would save a lot of digging around to ensure that the containers are set correctly...ugh

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 only internal connections.

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

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
 

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.

**Note** Immediately after you change the Admin Default Gateway, you will lose WUI access, and the next step must be from the console.

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 since we changed the admin gateway we lost WUI access. While in console, you will also need to reboot your device after changing the gateway.

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

In the console, login to your LoadMaster, and navigate to (4) Basic Setup.

Next, we'll choose option (4) Default Gateway Configuration.

Here, we'll set the GW to your DMZ Gateway, in my case this is my 10.x.68.x subnet then TAB down to OK and hit Enter when finished.

 

Next select (q) return to previous menu. Back at the main menu select (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 - this is not optional.

I added the word "external" to the service name that auto-populates: 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"

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 10.28.68.135 VIP and my Internal VS are on the 10.28.69.167 VIP.

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 but this time it'll be 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!

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
Description:
[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
Description:
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
Description:
An error occurred while using SSL configuration for endpoint 0.0.0.0:444.  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.

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.

Click OK

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

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:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

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.

Done!

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 ;)

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.

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."

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"

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.

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

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]

"ExcludeHttpsRootDomain"=dword:00000001

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.

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:

 

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!

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.

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!