If you haven’t downloaded it yet, don’t forget to listen to Episode 5 of the UC Architect, hosted this week by yours truly!
In this show, I’m joined by Michael De Rooij, Stale Hansen, Johan Veldhuis and Justin Morris and we discuss:
- MEC Topics!
- The new Hotmail, Outlook.com!!
- DirSync Filtering!!!
- Multi-site Active/Active DAGs in Exchange 2010!!!!
- Best practices for publishing EWS through TMG for Lync!!!!!
- Troubleshooting tools and centralised logging in Lync 2013!!!!!!
- Stale’s amazing Lync 2013 roundup article!!!!!!!!
Last year, I wrote a script for pulling out information from Exchange 2007 log files on Windows Server 2003 to detail information about EWS, ActiveSync and WebDAV clients. The purpose of this script was primarily to make it easy to find out about client you need to test before moving to Exchange 2010.
I’ve been meaning for a while to make an update to the script, as one issue with original version is that is was aimed only at Windows 2003 servers – and naturally there are a fair few Windows 2008 and 2008 R2 servers running Exchange Server 2007. The script is also useful when checking out what’s in the current environment before migrating to Office 365, so it’s applicable to Exchange 2010 as well.
So, I’m pleased to say that I’ve finally updated the script to support Windows 2008, 2008 R2, and also tested the script against Exchange 2007 and 2010 logfiles.
As with the previous version, it’s a little slow on larger log files, taking an hour or so for a 500MB log file and for log files of around 3GB each it can take around 6 hours.. So a future Log Parser Studio version might be in order.
I had a fairly unusual request from one of my customers whilst performing the final stages of an Exchange migration. A while ago, the CEO wasn't able to lookup people to contact from the Global Address List due to connectivity problems and wanted "offline" access to the GAL from his phone.
The customer asked me if it would be possible for me to write a little script to effectively grab the GAL (they aren't a massive company) and copy it into the CEO's mailbox, into a dedicated Contacts folder, for example "OrgContacts". Whilst certainly not a great idea for a larger company, for a few hundred users it's not a bad idea, and in a previous post I've written something very similar, so in my spare time put together the following script…
What it does:
- Connects to the user mailbox using EWS as a the logged on Administrator, using impersonation.
- Checks if the dedicated contacts folder exists, and if so empties it.
- Gets the organization's users who have an email address set and at least a work phone or mobile phone number.
- Adds a contact for each of the above users, populating the contact's name, company, department, job title, email address and work and mobile phone numbers into the dedicated contacts folder.
As with the original script this is based on, you need to set up the impersonal for Exchange Web Services and install the Exchange Web Services Managed API 1.2 before using the script. The script uses the default installation location of the EWS Managed API, so if you've got it installed somewhere else, update the script.
To setup the pre-reqs, follow Setup of Exchange Web Services Impersonation and Installing the Exchange Web Services Managed API from the original article Using Powershell to import contacts into Exchange.
Additionally, the script expects to be used in the following scenario:
- To be executed from the Exchange Management Shell, so it can get the InternalURL for Exchange Web Services (EWS) from Exchange 2010 SP1 or SP2.
- The logged-in user is the administrator whom has impersonation rights over the mailbox you wish to copy contacts into.
Using the Copy-OrgContactsToUserContacts.ps1 Script
Once the pre-reqs are satisfied, run the script using the following parameters, substituting <mailbox> with the name of the Mailbox User you wish to create the Contacts folder within:
Upon initial and subsequent executions, the script should output similar to shown below:
Finally, the new contacts folder, complete with copies of GAL entries should show within the user's mailbox, as shown below in OWA:
Download the Copy-OrgContactsToUserContacts.ps1 here as a zip file, and as always if you've got any questions or suggestions for improvement, let me know in the comments below..
Recently for a customer, as part of migrating from a competing solution to Forefront Online Protection for Exchange, we implemented Directory-Based Edge Blocking, the feature that synchronises the on-premises Exchange Server recipients with the FOPE service.
Due to the large number of recipients, I thought it would be worthwhile, in addition to other tests, to have a script that can verify that these addresses would in fact be accepted before changing Edge Blocking from Test Mode and/or changing the MX (Mail Exchanger) records over from the old service to FOPE.
On a manual basis you can test individual addresses by using telnet to connect to port 25 (SMTP) on the FOPE mail exchanger address and testing the recipient name.
Below you'll see what happens if I input an address that doesn't exist:
To perform this across a few thousand recipients isn't really practical, so I whipped up a quick PowerShell script that does this and records the results to a CSV file. It's not perfect, but the process is as follows:
- Export all recipients from Exchange to a file
- Copy that file to a workstation connected that will attempt to connect to FOPE from a different IP address to the ones that are used to relay through FOPE - for example an ADSL line used for testing.
- Run the script using the recipients file as input to the script, specifying the domain you wish to test.
- Examine the results from the file to check for any that should be accepted, but aren't.
First up, let’s look at how to export the recipients. What we want to do is get all Exchange recipients, and store the resulting PowerShell object as a file that can be re-used:
Get-Recipient -ResultSize Unlimited | Export-Clixml .\recipients.xml
Once that file's copied to the workstation, run the script, specifying the file and the domain:
.\TestFOPEAddress.ps1 -RecipientFile .\recipients.xml -AcceptedDomainToTest domain.com
Once running, you'll see the standard PowerShell progress bar reporting progress. Bear in mind, this is a simple little script, so this is kind of as advanced as it gets J
The resulting file is a CSV file named after the domain - e.g. domain.com.csv. Open this in Excel, and you'll be able to see the addresses checked, the result and filter for any errors:
If you get any errors - you want to first, re-check manually and double check the event logs on your FOPE Directory Sync server. You'll see errors for users that weren't uploaded here; and you should see the users including any secondary addresses in the FOPE Administration Center. However if you've got this point, those areas should already have been checked and this is just a belt and braces attempt at making sure we everything tested so far definitely works.
As usual, the script is available for download from here (Link non-functional for edit - check back later).
Updated 21/04/2012: Windows 2008+ compatible script uploaded and verified working against Exchange 2007 and Exchange 2010
When you're moving from Exchange 2007 to Exchange 2010 there are a few gotchas that it's worth watching out for in the planning stages before you change over Client Access Namespaces or start migrating Mailboxes. If you don't you might find you have broken Exchange 2007 clients, due to the CAS changes, and find some clients can't connect after their mailboxes are migrated.
When it comes to the Windows version of Outlook, you can find out about currently logged-in clients using the Get-LogonStatistics command; however you also need to be aware of other clients using protocols like ActiveSync, Exchange Web Services and of course WebDAV.
ActiveSync clients will mostly be fine with CAS Namespace changes, as depending on version they should be automatically proxied from Exchange 2010 back to Exchange 2007 or should autodiscover; however some clients like the iPhone don't work properly and you need to consider a workaround.
Exchange Web Services clients, for the most part, shouldn't have issues thanks to AutoDiscover, however it's good to understand what clients you have out there already so you can test and plan for any issues. There's a number of iPhone apps that use EWS out there that your users may have bought and I've seen some funny issues myself with the EWS version Mac Mail on Snow Leopard that may require a client visit.
Finally, WebDAV. There's little to explain about WebDAV apart from it's not supported in Exchange 2010! You need to find these clients (think Entourage 2004 and 2008) and upgrade them.
Unfortunately there isn't anything built-in to Exchange 2007 or 2010 to examine this data, but the good news is it should all be available to you via the IIS log files. Whilst logparser is pretty good, personally I wanted the data collected and grouped all in one go ready to use. And that's where this script came from…
What information does the script output provide?
The output from the script is in CSV format, so it's easy to use in Excel for further data processing. The CSV file itself has the following fields:
Username: Logon name of the user
ActiveSyncUser: If the user uses an ActiveSync mobile device
ActiveSyncProxyUser: If the user is currently being proxied through to this client access server
ActiveSyncClients: A semi-colon separated list of the clients in use, eg. iPad;htchero;
ActiveSyncLastAccess: Last date found for ActiveSync use
EWSUser: If the user uses some sort of Exchange Web Services client
EWSPCOutlook: Version information if the user has the Windows version of Outlook 2007 or 2010
EWSMacMail: Version information if user has the EWS version of Mac Mail
EWSMacOutlook: Version information if the user has Mac Outlook 2011
EWSEntourage: Version information if the user has Entourage 2008, Web Services Edition
EWSOther: A semi-colon separated list of any other EWS clients the user has
EWSLastAccess: Last date found for EWS use
WebDavUser: If the user uses some sort of WebDAV Exchange client
WebDavClient: A semi-colon separated list of WebDAV client software and versions in use
WebDavLastAccess: Last date found for WebDAV use
In an actual export, the above looks a little bit like this (apart from the blurry usernames!)
How to use the script
Example one - Parses log files from the default log directory "C:\WINDOWS\system32\LogFiles\W3SVC1" to "C:\output.csv"
Example two - Parses the last 30 days of log files from the current directory to cas_results.csv in the current directory, and saves the state to state.xml in the current directory (could take a LONG time!)
ExIISLogParser.ps1 -LogFilePath ".\" -Days 30 -OutputCSVFile ".\cas_results.csv" -SaveStateFile ".\state.xml"