Use PowerShell to Determine what Outlook Client Versions are accessing your Exchange Servers

Earlier this month I saw a blog article on “The EXPTA {blog}” about “Reporting Outlook Client Versions Using Log Parser Studio” and I thought I would show you a simple alternative using PowerShell that accomplishes the same task while giving you some additional flexibility.

This simple PowerShell function can be used to parse the Exchange Server RPC logs.

Piping this command to Out-GridView provides the same output in a similar looking interface as what was seen in the blog article mentioned earlier that was linked to.


While you could accomplish this task as shown in the previous example, you would be pulling all of the log files across the network only to process and sort them down on your computer which may not make your network administrators too happy. A better approach might be to add the function to a module on the Exchange server.

In the following example, we’ve done just that. The function has been added to a module that exists on the actual Exchange server in a location specified in the $env:PSModulePath and PowerShell version 3 introduced module auto-loading so no need to explicitly import the module. We’ll take advantage of PowerShell remoting so the filtering and processing is performed on the Exchange Server itself. Notice that we’re only grabbing the log files that have been modified in the last 90 days in this example. Using this method, only the results are transmitted across the network to our workstation. We’ve also specifed alternate credentials for the command to be run on the Exchange server since being logged into your workstation or even running PowerShell with domain elevated credentials is trouble waiting for a place to happen.


Here’s the type of output that is generated and it’s easy enough to sort inside of Out-GridView instead of manually adding that to the PowerShell function itself which would adversely affect the performance since all of the results would have to finish processing before any of them would be displayed.


While that’s nice and all, why stop there when we have the Power of PowerShell (with a capital “P” no less) at our fingertips?

Not sure about you, but 15.0.4615.1000 and 12.0.6672.5000 doesn’t mean much to me other than being a manual process to search TechNet to determine what versions of Outlook those are for each and every version, each time we run this. If you’re going to do something more than once, do it in PowerShell and be done with it <period>. What do I mean? Look up the build number to version translation once and write another reusable PowerShell function to automatically perform the translation for us from now on.

A simple helper function that translates the Outlook build number to the actual version has been created and minor modifications have been made to the original function as shown below. I’ve separated the function to translate the build number to the version to also make it into a reusable function in case I ever want to use it with another process.

Now we have a human readable version of Outlook displayed in the results.


Based on those results, I have users using unpatched versions of Outlook 2007 and 2013. Sounds like it’s time to enter a help desk ticket for the desktop group to get that corrected.

The nice thing about writing a reusable function like this is it’s multipurpose so I can use it not only with Out-GridView, but since its output produces objects, the results can be sent to a text, CSV, or HTML file, an email message, or worked with further such as to uniquely return a list of all Outlook client versions that have accessed this Exchange Server.


How long did it take to create these functions? Not long as I had previously done something similar with IIS log files.



  1. Bernd Webster

    A username would be useful in the output as well. Otherwise it would be hard to find that iin an enterprise environment.

  2. Rika

    possible to list outlook 2011 for mac users?

  3. vroon85

    Looks great srcipt but still finding out how to run this script in exchange management shell, I am getting “The term ‘Get-MrRCAProtocolLog’ is not recognized” error.

    I am having Exchange 2010 SP3 RU7 in our environment I’ve upgraded powershell version to 3 on one machine to run this script but still no luck, any help on how to run this script will be much appreciated.

  4. Cheryl Bergstrom

    I am also getting the The term ‘Get-MrRCAProtocolLog’ is not recognized” error. I am running Exchange 2013, powershell v. 4.
    We are in the process of upgrading all our clients from Outlook 2007 to 2013 and I would love to make this script work so I can easily find what clients we have that have not been upgraded.
    Other than here, I can find no references to the Get-MrRCAProtocolLog.

    • Eric W

      The function that Mike posted in his code sample starts with “Get-MrRCAProtocolLog’ (see line 2). You need to copy all the code into a text editor and save as a PS1 file and run from there..

  5. Sebastian Mair

    any help how to implement this function?

  6. ahmer zaidi

    I am trying to run this script with no luck, I do not get any error message neither any output, does anyone had any luck with this script?

  7. Thilo

    Thank you very much

  8. EDer

    unfortunately it does not work. I’m running on Exchange 2016. It just did not return anything to me.

    Powershell version:

    Get-Host | Select-Object Version


    Get-ChildItem -Path ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging\RPC Client Access\*.log’ | .\Get-MrRCAProtocolLo
    g.ps1 | Out-GridView -Title ‘Outlook Client Versions’

  9. divadiow

    same, sadly.

    [PS] C:\users\bloggsj\desktop>Get-ChildItem -Path ‘\\mail-1a\c$\Program Files\Microsoft\Exchange Server\V15\Logg
    ing\RPC Client Access\*.log’ | Get-MrRCAProtocolLog | Out-GridView -Title ‘Outlook Client Versions’
    Get-MrRCAProtocolLog : The term ‘Get-MrRCAProtocolLog’ is not recognized as the name of a cmdlet, function, script
    file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct
    and try again.
    At line:1 char:120
    + … r\V15\Logging\RPC Client Access\*.log’ | Get-MrRCAProtocolLog | Out-G …
    + ~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : ObjectNotFound: (Get-MrRCAProtocolLog:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

    Suggestion [3,General]: The command Get-MrRCAProtocolLog was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default. If you trust this command, instead type: “.\Get-MrRCAProtocolLog”. See “get-help about_Command_Precedence” for more details.


Leave a Reply to Eric W Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: