Tuesday, March 29, 2011

Exchange 2010 Administrator Audit log Powershell GUI

An interesting and useful new feature of Exchange 2010 is Administrator audit logging where each time a EMS cmdlet is run in the Exchange in the EMS, EMC or ECP this is logged. Within ECP you can do a search of the admin Audit logs and have the result emailed to you and what you receive in your inbox is an email with an a attachment called searchresult.xml. While this file contains a lot of great information there are a few problems with this format for administrators firstly is that OWA and Oultook will usually block the XML attachments so it can firstly be hard to get to the attachment. Secondly XML isn't the most readable format when it comes to trying to intemperate what was going on especially if you search across a larger number of days. So what I've put together is a GUI that first uses the EWS Managed API to find these any of these emails within your inbox and then gives you the option of exporting the raw xml or converting the XML to a CSV file or lastly using a separate report winform that groups the data retrieved and displays it back to the user. The later i think is a lot more useful as it lets you work more intuitively with the data and the better you can do this the more likely it is that you would spot an abnormality which is one to the purposes of auditing. eg this is what it looks like

Note this GUI currently only handles the Admin Audit logs not the Mailbox Audit log which are in a different format.

I've put a download of this script here

Sunday, March 27, 2011

Dealing with Invalid Delegates with Exchange Web Services and Powershell

Invalid delegates have always been a tricky issue in Exchange an Invalid delegate happens when a mailbox that has a delegate setup and the delegate user account is deleted or disabled(has the Exchange attributes removed). When your using the EWS delegate operations and a mailbox has an invalid delegate you get a message back to tell you the delegate doesn't map to an active directory user however it doesn't tell you who that user was and what type of delegate access that user had. You also can't use the EWS delegate operations to remove a user in this state so you end up with a kind of stalemate solution that requires a manual delete with Outlook. Before going any further its worth covering briefly what happens when you add a delegate to mailbox within Oultook there are three areas of the delegator's mailbox that gets modified.
  • Local freebusy object in the mailbox
  • Permissions on folders that are given access to
  • Rules collection if forward meeting requests option selected
The last things that gets changed is the publicDelegates active directory property.

What happens to the LocalFreeBusy object is of the most interest and has been documented in the http://msdn.microsoft.com/en-us/library/cc425488%28v=exchg.80%29.aspx protocol document basically it comes down to the following 7 Mapi properties on the LocalFreeBusy object.



These last three properties contain specific setting for each delegate user including the X500DN of the delegated users within PidTagScheduleInfoDelegateEntryIds (Its stored as Addessbook entryid).

If your observant you would have only counted 5 properties which is all that are documented in the protocol document. If you look at the object with a Mapi editor however you would discover two more undocumented properties that also hold information about delegates.

x6870 and x6871

To get the localfreebusy object in a mailbox using EWS there are a few methods you can use the first is to search the NON_IPM_Subtree for and find the FreeBusy Data folder and then search that folder for an item with a subject of localfreebusy. The other option is to use is the PR_FREEBUSY_ENTRYIDS extended property on the Non_IPM_Subtree which contains an array of FreeBusy EntryID's which the 2nd element is the LocalFreeBusy Object which you can convert into a EWSid using a convertid operation and then bind directly to that item.

So if your using EWS and you get "The delegate does not map to a user in the Active Directory" and you want to find out which user this refers to you can compare whats returned in PidTagScheduleInfoDelegateNamesW with the valid delegates you back with normal operation you should be able to work out the invalid delegate.

Thursday, March 10, 2011

Using the PR_Folder_Path property in Exchange Web Services to show the folder path

The PR_Folder_PathName Mapi property is a useful property to use when migrating an application that uses WebDAV to EWS where the webdav application has used the DAV:href property paths or if you just want to display the fullpath to a folder delimited by "\" which may useful for other applications.

The PR_Folder_PathName property returns the fullpath to a folder that is delimited by the byte order mark FE-FF so if you want to return a \ delimited path you need to replace these values in the Unicode string that is returned when you retrieve this property.

eg in the managed API

static void getPath(ExchangeService service) {
ExtendedPropertyDefinition PR_Folder_Path = new ExtendedPropertyDefinition(26293, MapiPropertyType.String);
PropertySet psPropSet = new PropertySet(BasePropertySet.FirstClassProperties) { PR_Folder_Path };
Folder foFolder = Folder.Bind(service, WellKnownFolderName.RecoverableItemsDeletions, psPropSet);
Object fpPath = null;
foFolder.TryGetProperty(PR_Folder_Path,out fpPath);
String fpPathString = Encoding.Unicode.GetString(HexStringToByteArray(BitConverter.ToString(UnicodeEncoding.Unicode.GetBytes((String)fpPath)).Replace("FE-FF", "5C-00").Replace("-", "")));

static Byte[] HexStringToByteArray(String HexString)
Byte[] ByteArray = new Byte[HexString.Length / 2];
for (int i = 0; i < HexString.Length; i += 2)
ByteArray[i / 2] = Convert.ToByte(HexString.Substring(i, 2), 16);
return ByteArray;