Sometimes I find some tools, scripts, and workarounds, and I like to bookmark them and when possible, download them to my Dropbox just in case they come in handy later on. The Exchange Team recently blogged about a very cool script that helps gather Exchange Logs from all of your Exchange 2010 and 2013 servers, with a huge ton of switches. With all the power of this script at my fingertips, log gathering is now a piece of cake, so I thought it would be great to let you know about it too in case you missed it.
David Paulson uploaded his PowerShell script CollectLogsScript.ps1 to the TechNet Gallery a few weeks ago. For what appears to be his first contribution, this script is really cool and it can do a great deal of things too. For starters, it can collect in a single run whatever logs you need from all of your servers at once, dropping them wherever you need to keep them. That makes it easy to parse through them all with Log Parser Studio, which you can download from here in case you don’t have it. But let’s take a look at all the things this script can do.
You can control just what you want from the servers, and include the number of days’ worth of log files it fetches (the default is three.) You can grab all of the available log files, or narrow your search to just the specific type of log files you want to grab. If you have 7-zip installed, you can also zip them all up, so if you are just trying to automate a grab of logs “just in case” this is a great thing to run in a scheduled task.
From Paulson’s documentation, here’s a list of all the switches that his script supports.
- FilePath – Specify the location on where you would like the data copied over and saved to (Default C:\MS_Logs_Collection)
- EWSLogs – EWS Logs are collected
- IISLogs – collects the IIS logs based off the default location, unless you specify the logging directory. This switch also collects the HTTPErr logs.
- IISLogDirectory – Allows you to use a different location (D:\logs\IIS) Note: your next directory in this path should be W3SVC1, otherwise it won’t work.
- ManagedAvailability – Collects the MA logs of Exchange 2013
- PerformanceLogs – Collects the default performance logs of Exchange 2013
- CustomData – Allows you to collect the whole directory of data
- CustomDataDirectory – Specifies the location of that custom data directory
- RpcHttpLogs – Collects the RPC logs and the RCA logs
- EASLogs – Collects the EAS logs for Exchange 2013 (Not the active sync logging per device)
- AutoDLogs – Collects the AutoD logs for Exchange 2013 and 2010
- OWALogs – Collects the OWA logs for Exchange 2013
- ADDriver – Collects the AD Driver logs for Exchange 2013
- ClusterLogs – Collects the cluster.log from the mailbox role server, as well as the clustering events
- NoAppSysLogs – Doesn’t collect the Application and System logs from the server (by default we always collect them)
- SevenZipIt – Allows you to use 7za.exe to zip up your files (recommended for 2010)
- MSInfo – Collects MSInfo from the server, plus the hotfixes, and the Exchange build number
- DiskCheckOverride – Allows you to override the disk free space check (15 GB if you are zipping up the files, 25 GB if you are not)
- AllPossibleLogs – Set all the switches to True
- NOZIP – Doesn’t zip up the informaiton
- DaysWorth – Sets the days back to collect the logs for IIS, Performance, HTTPErr logs. Default value is 3 days.
- DatabaseFailoverIssue – Sets the ManagedAvailability, PerformanceLogs, ClusterLogs switches to true. This will collect the best data possible to help determine a database failover. Note: recommend to run on all nodes of the DAG.
Some of the very cool things this script does include:
- Checking for free disk space before beginning the grab, which is good considering how large some of these log files can get!
- Fetches server information using MSInfo32
- Can report on all hotfixes installed
- Automatically grabs failover information when relevant
- Estimates progress and reports it, so you know something is going on rather than just looking at a blinking cursor.
The script needs to run from an Exchange server, either 2010 or 2013, and cannot work with Exchange 2007. That said, if you are an Exchange admin with 2010 or 2013, this is a great script to add to your toolbox. Enjoy!