Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Find Outlook rules that are deleting a message

As part of troubleshooting something I needed to quickly find what Outlook rules the user had for deleting messages. So I came up with this one-liner.

The result is a list of rule names and a friendly description of what the rule does.

Run this from the EMS of course.

Tip: Overriding a GPO setting via Registry

At work our Desktops team has put a policy in place that enables Outlook cached mode for every one. Which becomes a pain in the a$$ when you have to disable and enable cached mode for some users as part of fixing issues (OST file corruptions, no incoming emails, etc).

Thankfully this is a setting you can temporarily override via the registry. Just got to modify a key under HKCU.

But … if you open the registry as the affected user and try modifying the key, you can’t because of lack of permission. Expected, right? What’s the point of a policy if users can modify the registry directly to override it. Admin users can modify the key, but if you open the registry as an admin then HKCU points to the admin and not the user.

Here’s how you workaround though: open the registry by doing a “run as” as the admin. Then go to HKEY_USERS. One of the entries there will be for the user logged in. (There shouldn’t be many entries, but if there are then you can find the one you want in one of two ways: (1) Use psgetsid from the Sysnternals tools to find the SID of the logged in user. That’s the entry you want. Or (2) go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. You will find entries there with the same names as under HKEY_USERS. Check the ProfileImagePath key in each – the one with the path to the logged in user is the key you want).

Once you find the key of the logged in user under HKEY_USERS that’s it. Everything under here is the HKCU of the logged in user so any changes you make here reflect HKCU. Go ahead and change whatever you want – the change will succeed because you are now using an admin account to make changes to the logged in user’s HKCU. Hah!

Hope this helps someone.

Outlook 2010, Contacts, InterAction

Had a good time with one the secretaries today helping him out with Outlook contacts and the Country field.

By default Outlook has a Country field you can sort on or group by. But what is this Country field? You have the option of setting a business address, a home address, and an “other” address; but there’s no option to define a Country value independent of these. Through trial and error I figured that the Country field is automatically set by Outlook when you set a Business/ Home/ Other country. Which makes sense. (I didn’t test what happens if the countries for each of these are different. My guess is the last modified entry takes precedence).

Anyways, there’s a catch with the Country field being automatically set this way. If you create a contact in Outlook it works, but what if the contact is added some other way? Maybe the contact is imported, or in our case we use a CRM software called InterAction which syncs Outlook contacts with its database.

When someone adds a contact to InterAction and set the Business Country as something, Outlook doesn’t automatically set the Country value while syncing. Even opening and save/ closing the contact in Outlook doesn’t help. You have to open the contact, go to the Business address field, and then save/ close for Outlook to set the Country field. That’s not very practical so in general it’s wiser to ignore the Country field in Outlook and use the Business/ Home/ Other country field.

That was the first issue the secretary had. Next was that many Outlook contacts that didn’t have a Business Country had the value set as United Kingdom in InterAction. That’s odd because the value should have synced! I tracked it down to an InterAction setting. You see, when you make a new contact in InterAction it expects a Business Country field and leaves the default as United Kingdom (possibly a setting from our admins). But what happens is that – and this is a big I think – if a contact you open in InterAction does not have a Business Country value then it shows a value of United Kingdom even though the value is actually empty! That’s why InterAction showed these contacts as of being in the UK while Outlook had a null value.

Nice. That’s two things sorted for the secretary.

The last thing was how can he enter the correct Business Country values? For this I first grouped his contacts by the Business Country field and then sorted by the Business Phone field. This way I could see in one place all the entries that needed fixing, and based on their phone number I can decide which country they must belong to. So can I batch change the Business Country value? Sure! Once you group the contacts thus (by the field you want changing, in this case Business Country) select multiple contacts and drag and drop to the group you want and their field is automatically updated. Sweet! To make it even easier if you have many groups, simply go to the View tab and collapse all groups initially. Then expand the one without Business Country, and drag and drop to the group you want. Easy peasy!

That’s all. No screenshots as I typed this post from my iPhone using the WordPress app.

Enabling disabled Office add-ins automatically

So as I mentioned yesterday I have been thinking of using Task Scheduler to try and enable disabled Office add-ins automatically.

The Problem

Here’s what happens. Every so often when users open Word, Outlook, Excel, etc they get a prompt like the one below:

addin-error

We don’t know why they keep getting it, but ideally users should be clicking “NO” as we use all these add-ins and don’t want them disabled. But users being users they click “YES” intentionally or inadvertently and then call IT with complaints that their Word, Outlook, etc aren’t working as expected. Then we in IT have to do the boring task of going to their add-ins screen and enabling these items; followed by closing and opening Word, Outlook, whatever.

What I want to do here is (1) warn users when the above dialog box comes up, advising them not to click the “YES” button; and (2) if they do click “YES” then somehow enable the add-ins behind their back and get them to close and open the affected program.

Add-ins and the registry

I started off thinking I might need to do some fancy stuff to enable add-ins, but soon realized that they are all controlled by the registry. Nice!

  • Add-ins can be installed for all users on the machine or just a specific user. So you have to look under both HKLM and HKCU. The two locations are: addin-registryHKCU\Software\Microsoft\Office\(application)\Addins\ and HKLM\Software\Microsoft\Office\(application)\Addins\ (replace (application) with Word, Outlook, Excel, or PowerPoint). These two locations contain keys for each add-in installed for that particular application.Here’s a screen shot for the Outlook InterAction add-in for a user.
  • The key thing in the registry keys above is the LoadBehavior entry. This can take many values – the default is a value of 3 which means the add-in is loaded automatically at startup and is currently loaded. If the value is 2 it means the add-in is loaded automatically at startup but is currently not loaded.
  • My initial hunch was that LoadBehavior is what I must target. I thought when a user disables an add-in the LoadBehavior value of that add-in probably changes to 2, so all I need to do is switch it back to 3. But I was wrong (as I quickly figured after crashing Word a couple of times and choosing to disable add-ins).
  • Then I discovered that add-ins which are disabled via a user dialog box as above don’t have their LoadBehavior value changed; rather they are set as disabled at another place in the registry. And that is under the HKCU hive, at HKCU\Software\Microsoft\Office\(version)\(application)\Resiliency\DisabledItems (replace (version) with 15.0 for Office 2013, 14.0 for Office 2010, 12.0 for Office 2007, 11.0 for Office 2003, you get the idea … and replace (application) with Word, Outlook, etc as before).

Each time an add-in is disabled, a REG_BINARY entry is created under HKCU\Software\Microsoft\Office\(version)\(application)\Resiliency\DisabledItems with a binary value. I didn’t experiment to see if there’s a one-to-one mapping between this entry and an add-in, and also whether the entry is same for an add-in across all machines; the important finding for me was that if I delete this entry, it enables the add-in. So all I really needed to do to see if there are disabled add-ins for a program is to just check this key, and if there are any entries I can delete them all to re-enable all the add-ins. Nice! This doesn’t require a PowerShell script really. Good old reg can do the trick too. So a batch file is more than sufficient.

Below is what I came up with:

I could probably make it shorter if I pick up more batch file scripting but this does the trick for me.

Let’s break it down for Outlook. I enumerate the registry key. The results of this are iterated over by a FOR loop. If the list isn’t empty – i.e. there are disabled add-ins – the loop exits and goes to a different section.

This section that the loop exits to simply deletes all entries under that key, shows a message to the user asking them to close and open Outlook, and goes up the batch file to check Word next.

Repeat and rinse for each application and there you have it! Like I said, easy peasy, quick and dirty!

Maybe I should improve the script later – I don’t know. An overhaul using PowerShell might be a good idea I think. Specifically, there are a few things I am already thinking of adding:

  1. Currently the message box goes away if the user clicks OK. Would be nice if I could keep an eye out for whether they actually close the program later, and if not keep popping up reminders – maybe a ballon tip?
  2. Would be nice if I could close the application for the user. I could do that in the batch file too via taskkill but I was wary of doing that lest it cause any corruptions. I wouldn’t want Outlook OST and PST files or Word templates getting corrupted because I closed the program. Maybe PowerShell has a more graceful way of shutting down an app? I don’t think so, but that could be my ignorance.
  3. Currently I enable all add-ins. While that’s fine for our case maybe I should have a list of add-ins that are to be excluded from being enabled? Or only enable a whitelist of add-ins?

So that’s that. Next step is to find a way to trigger the batch file.

Scheduled task triggers and Event Viewer

Each time the dialog box asking a user to disable an add-in appears, an entry is logged in Event Viewer. This looked like a promising way to hook on to that event and warn the user not to click “YES”. These entries are logged under “Application and Services Logs” > “Microsoft Office Alerts”.

addin-ev-alert

The joy of discovering that was short lived though, as I realized the same sort of alerts are generated for many other Office related things: spell check notifications, connectivity to Exchange, etc.

misc-ev-alert

All these alerts had the same source and ID and there was nothing for me to distinguish between them! Sure the data part was different, and while Event Viewer (and thus Task Scheduler) supports XPath for searching the Event Logs it has limitations in that I can’t do wildcard searches. Thus while I could do an XPath search for all events that have the exact error message in the first Event Log entry above, I can’t do an XPath search for all events that contain the text “Do you want to disable this add-in?”. This is a big limitation because now I will have to (a) find the exact message for each add-in and program, and (b) create XPath queries for each of these – eugh! That’s too much work for now (and not very elegant either!) so I decided to not pursue that route.

Once a user decides to enable or disable an add-in though, I found a different alert is generated for that. Under the “Application” log, from source “Microsoft Office 14” (since we have Office 2010), alerts with event ID 2001 are generated each time a user selects to disable an add-in (and alerts with event ID 2000 are generated when they choose not to disable).

2001-alert

That’s convenient, coz now I can create a task that is triggered on such events and whose action is to run the previous batch file. Nice!

Putting it all together

End result is a task I can import as in the case of the laptop lid issue. Here’s the XML file of the task:

Once again, I install it for the users I want via a batch file like this:

Not done yet!

I am not done yet though. It’s not practical installing it like this for each user in my domain. I chose the above approach just to get it installed for a few test users; next step is to roll it out via GPO to the whole domain. Stay tuned for a post on that later …!

And one more thing …

Something I learnt while reading about add-ins.

Outlook search and additional mailboxes

Something to keep in mind regarding Outlook searches and additional mailbox. The comments below are in the context of Outlook 2010 and Exchange 2010 as that’s what we use at work.

There’s two different search providers that come into play when searching via Outlook. They are used depending on how the mailbox is accessed by Outlook.

search optionsIf the mailbox is accessed in cached mode (so the folders are actually in an OST file on your computer) or if you are searching a PSTsearch locations file, Outlook uses Windows Desktop Search (WDS) to do the search. WDS is set to index many locations on your computer and if there are OST and PST files in Outlook it indexes these too. You can tweak WDS’s options by clicking on “Search Tools” and then “Search Options”. Click “Indexing Options” in the window that opens to change the locations and file types that are indexed.

However, if the mailbox is accessed in online mode (so there are no OST files involved) Outlook passes your search query to the Exchange server who then returns with results.

This distinction doesn’t usually matter except when searching attachment contents. In that scenario WDS returns more results as it is able to index more file types. The Exchange server in contrast has a lesser number of default file types it can index and it is up to the Exchange admin to install filters for additional file types.

At work, for instance, all our users access their own mailboxes in cached mode – so search results there are more comprehensive when compared to search results from additional shared mailboxes that are accessed in online mode. The PDF file type is not included in the default file types for Exchange 2010, so shared mailbox searches don’t return emails with PDF attachments even if they contain the search term. Excel and Word file types are returned in the results though.

This is a good link to read for more info.