MODX Evo server move causes error about unspecified timezone in PHP

Having just moved a MODX Evolution based website from the old server to a 1and1 VPS, we started getting errors about not specifying a timezone in PHP. Tried several suggestions around updating htaccess but no luck.

Adding this line to the index.php did the trick.

ini_set("date.timezone", "Europe/London");

Apparently its because the default PHP setting on the 1&1 VPS is to use Fast CGI

Exporting / copying results from Exchange 2007 Message Tracking troubleshooting assistant

I was trying to track down some specific invoice emails that had allegedly been sent a couple of weeks earlier. Its easy enough to fire up the Message Tracking troubleshooting assistant from the Exchange 2007 Management Console, just look in the Toolbox section. Its a bit like the old Message Tracking Center in Exchange System Manager from the 2003 version.

You specify your message criteria and date range and it shows you all the matching email records. However you really need to get it into Excel to start filtering and sorting the data usefully, especially when it returns 100s of matching emails. However there isn't an obvious copy or export option.

The trick is to click Go Back and look at the shell command that was generated, at the bottom. You can see in this screenshot the equivalent shell command is


get-messagetrackinglog -EventID "SEND" -MessageSubject "invoice" -Start "16/11/2014 07:58:00" -End "28/11/2014 21:08:00"

Copy that line, then start Exchange Management Shell and paste the command (You need to click the shell icon top left then choose the Edit submenu). Before you hit enter to run the command, paste the following to the end of the line: 
| export-csv c:\windows\temp\results.csv
(the | is the Shifted backslash symbol just by Z on the UK keyboard, its the pipe command) 

That will create an Excel friendly report in the Windows\Temp directory

Uninstall Exchange Server 2010 SP3 Rollup 8 requires msexchange.msi

Having been caught with an SBS 2011 server that had the Exchange Server 2010 Service Pack 3 Rollup 8 loaded, just before Microsoft withdrew that update. Apparently it caused connection problems with Outlook clients, although we had no reported issues.

Before you start make sure you've downloaded Exchange 2010 Service Pack 3 and run it, so that its unpacked in a handy directory.

Going into Control Panel > Programs > View Installed Updates, you should see Exchange 2010 SP3 Rollup 7 and Rollup 8.

Select and uninstall Rollup 8. It takes a while to complete but will prompt for the location of msexchange.msi. This is actually the original  SP3 installer, not anything to do with RU7 which is what you'd expect. So when it prompts, browse to the SP3 directory mentioned above, where you already unpacked the files, and choose that msi file.

The RU8 will uninstall and appear to leave RU7 on the updates list, however in reality your Exchange server is now all the way back at SP3 with no Rollups at all.

Reinstall Exchange 2010 SP3 RU7 to bring it back up to date - and wait for MS to reissue RU8.

Bad week for faulty updates!

Offline Files error - 0x80070718 Not enough quota is available to process this command

I was copying files from an old PC to a Win7 64 bit laptop for a client with an SBS2011 server. The laptop was at home, offline, when it started warning about not being able to copy any more files - to be fair there were 20GB of photos involved.

Those laptops are setup to use Offline Files, so the Documents folder is available away from the office. Sounds an easy one, the SBS2011 server has a 2GB file quota for users by default. I checked it was turned off ok, then connected via VPN, tried another copy, still no luck. Double-checked that setting, turned it on and off, again no luck. Had to be something else - not as obvious unfortunately.

Tracked it down to a local limit on the laptop - the offline files disk usage limit was too low. Look in Control Panel > Sync Center > Offline Files > Manage Offline Files > Disk Usage > Change Limits

A more useful error message would have saved a bit of time there.