Tip o' the Week 351 – Searching the GAL
When Exchange Server first appeared in 1996, to deliver email like nothing ever seen before in the land of corporate email, one of its defining features was the directory service that held all sorts of details about users & groups, and could be populated with phone numbers, manager-employee reporting relationships and all sorts of other data, custom or otherwise. The Directory fed the Global Address List, or GAL, that was visible in the Exchange “Capone” mail client and later in Outlook – so that’s what you see as the address book when looking stuff up (tip: at the main Outlook window, just press CTRL+SHIFT+B to open the Address Book). Ever since Outlook 2003, the predominant way of looking up the address book is to refer to an offline copy called the OAB, and there’s a bunch of management that can be enacted on the OAB generation, by the operator of the Exchange Server. By and large, it’s a seamless exercise that users won’t notice, but you do sometimes see a bit of lag – like if a change is made to the directory (a user’s mailbox being created or deleted, for example) , it could take many hours to make it down to the address book on the client. Also, not all information is stored in the OAB, so looking for pictures or reporting line information, for example, will need your client to talk to the directory server, meaning it seems to lag behind everything else and won’t work at all when you’re offline. Since 2000, Exchange has used the Windows Active Directory rather than Exchange’s own; in fact the AD traces its own roots back to the Exchange one – including various detritus of the X.500 standard that was part of the original Exchange directory). One of the seemingly lesser-known features of the Offline Address Book in Outlook, is that contents themselves are indexed and searchable. Sure, you can search in the address book by “Name only” but all that does is jump to a place in the sorted list of the GAL; the sorted list that doesn’t let you sort and filter by any of the column headings – blame 1996 code for that… If you want to search other fields, just change the Search radio button to “More columns”, enter your text and hit Go. Sadly, you can’t use wildcards or anything, but you can join different searches as the logic seems to be combining all the words in an AND rather than OR fashion – so searching the Microsoft GAL for “ewan” currently returns 7 users and one DL, but searching “ewan UK” brings back the 3 of us based in the UK. There’s one thing to be aware of, though – the matching is still pretty basic – it only searches from the start of each field, so if there’s a Bob Robertson then looking for Robert or Roberts in the More columns search, will return Bob’s details but only if the “Surname” field is filled in (in other words, if you only had the display name of “Bob Robertson” then it wouldn’t get returned) . Ditto, searching for “son” won’t return Bob. Still, if the naming convention is orderly enough, it could still be useful – at Microsoft we do have a reasonably consistent naming scheme, so try searching for all the Steves in Edinburgh, or all the Patels in Hyderabad (hint – look at the location or department fields, and if the first few characters denote the building name or the division of the company, you could use that to search against). Or the Mc-somethings who work in building 9…? [The location field for Redmond employees starts with their building number – so 9/1234 would equate to room 1234 found on the first floor of building 9 – the trailing slash in the search example above stops results from building 99 being returned as well] |
Comments
- Anonymous
September 19, 2017
On the blaming the 1996 code for not being able to sort columns, since we are 10+ years down the road, can we get that fixed? Every other column in the software universe sorts when clicked on. What could it hurt?