Today’s post is about chunking email exports from Exchange 2007 with Powershell.
Back in the days of Exchange 5.5 through 2003, exporting a mailbox was done with ExMerge. Exchange admins had a love/hate relationship with ExMerge. It wasn’t the prettiest GUI around, but it got the job done.
Then along came Exchange 2007, and Microsoft decided that GUIs were overrated. So they gave us this wonderful thing called the Exchange Admin Console, using Powershell. Now you could export a mailbox with a single, non-intuitive command line.
Unfortunately, one of the side effects of ExMerge that went away was the ability to split PST files. Since ExMerge only supported ANSI PST format, it was limited to 2GB per file. As mailboxes had already started to grow and Exchange supported mailboxes much larger than 2 GB, ExMerge would automatically split a mailbox into multiple PST files. Now that the Export-Mailbox commandlet supports UNICODE PSTs, Microsoft apparently decided there was no longer a reason to split PST files.
But as I said, mailboxes have gotten MUCH larger. And journal mailboxes can be downright HUGE. So how can you export a 100GB journal mailbox without blowing up the export or creating a PST too large to open? Continue reading
UPDATE – At the bottom of the page, I have included an Excel macro to help cleanup the CSV output from Log Parser.
Investigations usually center around what was happening, and when. In a corporate environment, things can sometimes get turned on their heads.
Instead of concentrating on the WHAT, the primary focus could turn out be the WHEN. If there is an allegation that a user is ducking out early or working overtime without tracking it, it can be very important to know when they were logged into their computer. Comparing this information to time entry systems can show discrepancies that need to be addressed.
Fortunately, Windows logs much of this information for us by default. In Vista and above, the log file we need to look at is C:\Windows\System32\winevt\Logs\Security.evtx. We could go through the event log, line by line, but why when there is a better way?! (Windows XP also had a security event log, but because it did not log an event when a user locked a workstation, it was much less useful for building a usage timeline.) Continue reading
As a follow up to my earlier post on Reliability Monitor analysis, I have finished updating the ParseRacWmi tool to include the ability to parse the new Wmi.db format used by WIndows 8.1. You can download the tool here (SQL Compact 3.5 required to parse Windows 7 & 8 sdf files, get it here: http://www.microsoft.com/en-us/download/details.aspx?id=5783), or read on for more information about what has changed. The updated tool also has a few changes under the hood for processing the old SDF files, speeding up the process significantly. The proper usage from the command line is:
ParseRacWMI.exe [-win81] [-csv|-l2t] [-detail] path\to\[RacWmiDatabase.sdf|Wmi.db]
Note: Make a copy of the database file in another location and point the tool at the copy if you are running against a live machine.
There is now a DLL included with the executable, as I needed to tap into the wonderful Managed Esent API to read the new ESE format. The DLL needs to reside in the same directory as the executable.
The tool outputs to the console, so you will need to redirect the output to a file. CSV is a straight dump of all available fields, while L2T gives output suitable for inclusion into a timeline.
The ParseRacWmi tool mentioned here has been updated! See this post for more information.
The Windows Reliability Monitor is a tool that runs by default on all editions of Windows 7 and 8, as well as Vista and Server 2008. This diagnostic tool records changes to a computer that could possibly affect it’s stability, and can be reported on in a live system by digging deep into the control panel. This information can prove useful in developing a timeline of events for a forensic or incident response examination.
Some of the information logged by the Reliability Monitor include:
- Software installs, updates, modifications, and uninstalls
- Driver installation
- Windows Update installs (and failed installs)
- Application Faults
- Unexpected Shutdowns
- OS Information changes (Computer name change, etc)
As you can see, there are cases where having this information could be extremely useful. This information is not easily removed from the system, so even after someone clears event logs, this information would still be available. Continue reading
One problem for any organization that spans timezones is reporting on log information. For example, my organization collects web proxy logs across the US and Europe. All of these logs are pulled into a central repository (Splunk – one of the greatest worst programs I have ever used). To avoid confusion, all proxy devices report times in UTC.
This is very helpful until HR requests a report for a specific user. They are usually not keen on adjusting the times in their heads. If the date and time were in the same cell, you could just use the formula =A2 – TIME(HOURSBEHINDGMT,0,0). Even this has limitations, though. Here in AZ the formula would always be =A2 – TIME(7,0,0), but for users in other states, you would have to adjust it manually for daylight savings time(DST). Continue reading
Update: I have written a small utility that will take the encoded hash and decode it for us. After that, it will do a Google Search, which will often turn up the name of the file being downloaded. If not, you can take the decoded hash and search with it on several torrent tracker sites. You can download the code here.
Just about anyone who has performed investigations in corporate settings has run across a URL like this while reviewing proxy logs:
Clearly someone is torrenting on our network! If your logs are good enough, you probably even know who was doing it. But wouldn’t it be nice to know what they were trying to download?
I like to think I’m pretty good at tracking down information on the internet, but I had a really hard time figuring out how to decipher the information above to show me what the target of this torrent was. So here is what I discovered, in hopes that it will help someone else avoid the cursing and frustration that I went through. Continue reading
I know there are lots of options for blogs containing information on digital forensics, and I wouldn’t blame you a bit if you never even find this blog. I’m actually doing this for purely selfish reasons.
Every day in this field, we learn something new. Usually by necessity. A case comes along that is similar, but not quite identical to a case you worked on months before. You remember that you found a way to make sense of something and are wracking your brain to recall just what it was.
Maybe your Google-Fu led you to an article that inspired you, or maybe you just woke up in the middle of the night and figured out the problem you were fretting about for days before.
This is my site to store those kind of breakthroughs when I have them. Maybe your Google-Fu will lead you here when you face something similar. Maybe you came here to learn what NOT to do. Either way, it matters not to me.
Oh yeah, and the title of the blog? Pretty self explanatory as the mercury tops 112 degrees outside.