PowerShell Scripting: EWS and IPM.Configuration.Owa.UserOptions

NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.

So, to start off, I should explain how this script came about and why it’s, currently, in a ‘legacy’ status.

There was an issue in Exchange 2010 (that, has since, been fixed), where the save method for the IPM.Configuration.Owa.UserOptions item was in an infinite loop due to corruption. This corruption didn’t come into fruition until long after RTM and SP1. (My thoughts are that SP1 was the introduction of the “bad code”, but it’s not really important when it was introduced.)

What would happen is that the Mailbox Assistants would become flooded/backlogged with events, in the event history table – which is kept in memory. The only signs of reproduction of the issue was that OOFs and RBAs would not fire, in response to emails or meeting requests, respectively. This became a tedious issue to deal with because it also caused other problems, during initial attempts of remediation.

For example, mailbox moves would fail, as the Mailbox Replication Service would successfully move the mailbox but the assistants were still churning away at the mailbox. After the failure, and if the new mailbox on the target database was – now – oriented to the user’s object, the new database (a.k.a.: the target database) would quickly fall into repro.

Restarting the service and having it rebuild the event history table in memory was not a viable avenue for remediation, because the table would rebuild with the infinite corruption loop – once the assistants had read in the event history table, tagged the IPM item change to be processed, and the event was interesting to the assistant[s].

The method we would use to find these users, with the affected IPM item, is to use ExMon to see which user was consuming the most CPU. We could, then, use ExTra to obtain an ETL – targeting the ALL of the assistant flags. Then, we could use a program to port the ETL to CSV and see just what those assistants were chomping down on. [The ExTra method was my preferred method, as it provided two things: significant proof of repro and the user we needed to fix.]

Sadly, our only method of remediation (until SP2 + RU2 + IU) was to copy the user’s configuration settings (Get-MailboxMessageConfiguration) and, then, purge the item from the mailbox store. More often, than not, this was done with MFCMAPI and we would pass a hard delete, to prevent the corrupted item from going into the dumpster.

Then, I got a novel idea: if we use EWS, we can poke into the mailbox store and obtain the item for deletion, since it’s at the root level of the container. And the rest is, as they say, history.

I thought, even though this is legacy, it might prove note-worthy or that someone could learn from the interop of .NET with PowerShell. [All of the EWS calls are in C#.NET.] Unless we have a repro of this particular issue in the nigh to immediate future (for those who are concerned, it’s been over a year since this was fixed), the propensity of it ever being used again is $null. (Little PS humor, for ya, there…)

Delete-IPMConfigurationOWAUserOptions.ps1

Hybrid Configuration Wizard: Exchange server “” was not found. Please make sure you typed the name correctly.

NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.

When you decommission an Exchange Server in your Organization and have a Hybrid Configuration, one of the things that does not occur is that the server is not removed from the Hybrid Configuration (msExchCoexistenceRelationship) to reflect this. When you run the Hybrid Configuration Wizard, after the decommission, you’ll see the following error:

The wizard did not complete successfully. Please see the list below for error details.
Exchange server “<Server>” was not found. Please make sure you typed the name correctly.

 

Given the above, you’ll see something similar to the following in Exchange Management Shell for the Hybrid Configuration:

SendingTransportServers   : {UNDERJORDISKE
                            DEL:416ba20c-62c1-4a28-95e5-8dbb6430dc96, LJUSALFER
                            DEL:89bf8a7d-144f-43b8-8aee-b8ac6f98721f}

 

One method to resolve this issue is to do a modification of the object in Active Directory. Using ADSIEdit, browse to the configuration container and either go to the object’s path (Config container > Services > Microsoft Exchange > Organization Name > Hybrid Configuration) or just create a new query (objectClass=msExchCoexistenceRelationship). Once you have the object, look for the property you want to fix (in this case, it was ‘msExchCoexistenceTransportServers’). I removed the two defunct values.

I, then, used Exchange Management Shell to get the DistinguishedName of the current Transport Servers in the Organization:

Get-TransportService | FL DistinguishedName

DistinguishedName : CN=HYLDA,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=minvan,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=minvan,DC=se
DistinguishedName : CN=STROMKARLEN,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=minvan,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=minvan,DC=se

I copied these values into the same property I removed the defunct values, previously. After doing so, I re-ran the Hybrid Configuration Wizard.

SysInternals: How Handle Helped Me Figure Out Outlook Was Up to No Good

NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.

So, after a lengthy day of some C# battles, a few Exchange issues, and some ded.pixel blaring through the speakers, I went to clean-up some folders from my desktop. I received the dreaded ‘Folder In Use’ message from Windows:

Alright. That’s odd. All that’s in there is two csv files. Excel isn’t open. So, needless to say, I have no readily apparent signifier as to what’s got this folder on lock-down.

Enter handle. Handle is your friend, in these times of need.

O.k., Outlook. Why do you have a handle on the folder? Took a dump of the process of Outlook, closed it, and the file could then delete.

It’s up to the Outlook EEs to figure out why Outlook kept a handle on that file, now.