We can confirm this by using the df (disk free) command, which will display details of all the filesystems our login has access to – in this case, we are root so we can see all the filesystems on the box

So how to work out what is taking up space on root?

We can use the du (disk usage) command, with some additional arguements -s (report the sum for each directory, rather than each file in the directory) -k show as multiples of 1024bytes (default is 512). We then pipe this into sort with the -n (numerical) arguement

du -sk /*|sort -n

We can see from the screenshot that /var warrants further investigation

So we do du -sk /var/*|sort -n and then du -sk /var/hosts/*|sort -n

Continue using this technique to drill down until you find whats filling up all the space – here, the logs for four of our hosts were getting pretty large. I deleted some that were >6 months old which freed up almost 2 gig.

Summary

The df and du commands, together with sort, will enable you to quickly track down which files are consuming the most space on your filesystem.

Check your PHP version – one way of doing this is using phpinfo() – see this post

Before you start, it’s worth checking what has changed in the new version of PHP your upgrading too – obviously the bigger the version jump the more chance there is that some of your code will call deprecated functions and so will require updating before it will run correctly once the upgrade is complete.

Download the latest version from http://windows.php.net/download/ – you’ll want the stable, obviously. You’ll need to know whether you are using the thread safe or non-thread safe version. I use the thread-safe, which is the recommended one to use if you’re running Apache on Windows. Here, we want the .zip, not the installer.

If you want a bit more background on thread-safe vs non-thread-safe see this post

Before you start the upgrade, take a backup (or perhaps a snapshot, if it’s a virtual machine).I also take a copy of your PHP folder (in this case, C:\Program Files\PHP. This holds all of your existing config etc.

Rename the existing PHP folder to PHP.old

Create a new PHP folder

Extract/copy the contents of the .zip file to the PHP folder you just created

Copy your old php.ini (from the php.old folder) and paste it into your new php folder

Start Apache and then browse to your website and make sure everything works properly – as mentioned above, if your code is calling deprecated functions then it will need to be updated.

On the Apache side, this should be pretty straightforward, on the PHP side, I anticipate a load of code will need updating as it uses functions that are deprecated in PHP 5.3.x – I’m not a PHP programmer so someone else will deal with that.

So here goes…

Preparation

First off, grab the latest Apache binary from http://httpd.apache.org/download.cgi#apache22. You’ll want the MSI installer, not the source… This site doesn’t use SSL so we can go for the one without mod_ssl – obviously if you use SSL on your site, get the one that includes it!

Next, and before we go any further, take a backup of your server. In this case, the web server is a virtual machine so I take a snapshot. I also take a copy of the Apache folder, in my case this is located in C:\Program Files\Apache Software Foundation\Apache2.2. This folder contains all the Apache binaries and configuration.

Uninstall

When you un-install Apache (which we will do next) it should leave some of the folder in place – namely, your configuration.

Next, stop the Apache service, either using NET STOP apache2.2 or via the Services MMC snap-in

Uninstall Apache via Add/Remove programs

Once the uninstaller has completed, browse back to your Apache folder. You should see that some folders still remain, including your configuration

So that’s the uninstall completed, now we just need to install the new version

Install the new version

Launch the installer MSI

Just ‘Next’ through the installation wizard, when you get to the Server Information screen, you should see that the details are already filled in correctly. I’ve purposely obscured them here.

I go with a Typical setup

Then click Install to begin

Once installation completes, the Apache service should start, if not, do it manually via the Services MMC

IMPORTANT – by default, the Apache service will be set to run as LocalSystem. I strongly advise you to run with a less privileged account (as do Apache). If you don’t know how to do this, see the relevant part of http://unixhelp.ed.ac.uk/manual/platform/windows.html – or wait for my post on it later this week.

Assuming you were following this best-practice before, you’ll want to stop the service via the Services MMC and change it to use the correct account.

HELP – Apache wont start!

A useful tip if Apache won’t start – open a command prompt and attempt to start Apache, something like

cd c:\program files\apache software foundation\apache2.2\bin

httpd -t (using -t means it checks your httpd.conf syntax – if all is OK you will get

Here, I have deliberately broken my httpd.conf as an example.

Summary

All in all, a pretty simple upgrade (it took me around five minutes). Like all upgrades, the greater the version jump, the more likely you are to run into problems. It goes without saying that you should test this on your dev servers before upgrading anything in production.

To restart it log into the host and run

mgmt-vmware restart [to restart the VMWare management services]

Usually the service will just restart, but occasionally the hostd process gets stuck and you see

“Stopping VMWare ESX Management services:VMWare ESX Server Host Agent Watchdog [FAILED]“

If that happens, you will need to kill the hostd process manually as it’s preventing the management services from restarting.

To do this:-

[Log into host as root/become root]

cd /var/run/vmware

ls-l vmware-hostd.PID watchdog-hostd.PID [this should show the files that contain the PID (process ID's for the hostd and watchdog processes]

cat vmware-hostd.PID [to view the PID for the hostd process]

kill -9 <PID from above command> eg kill -9 1104 [this will kill the process]

rm vmware-hostd.PID watchdog-hostd.PID [to remove the files containing the PID information (these will be re-created with the correct PID when those processes are started]

service mgmt-vmware restart to restart the VMware management services

After a few seconds you should see the VM’s on the affected host now show as connected in Virtual Centre.

This file contains information that will assist you in determining the cause of the stop:-

List of drivers loaded at the time of the crash

Details of the stop message

Details of the process that crashed/stopped

There are several types of dumps that Windows can create, these are

a)A complete memory dump, which basically does exactly what it says on the tin.  The entire contents of physical memory at the time of the crash are wrotten to the dump file.  This type of dump is the default on Windows Server.  Your page file must be of a size at least equal to the amount of physical memory in the machine, plus 100mb for the header.  NOTE – this isn’t available on machine with more than 2GB, in which case the default is a kernel memory dump, written to the same location.   ADDITIONAL NOTE – creating a complete memory dump on a machine with at or close to 2GB of physical memory can take several minutes.

b)Kernel memory dump – Smaller than a complete memory dump, this contains kernel mode pages in physical memory at the time of the stop.  The size of the dump varies as it depends on the amount of memory allocated to kernel mode at the time.

c)Minidump (Small Memory Dump) – a 64k dump file is created which contains details of loaded drivers, stop code and details of the thread that caused the crash.

You can change what type of dumpfile your server creates by right-clicking My Computer, selecting Properties from the context menu to bring up the System Properties dialog and then clicking the Advanced tab.

Windows Recovery Options Dialog

Which type of dump should you use?  I tend to stick with the defaults – a full dump on a system with <2GB physical memory, kernel dump on systems with >2GB

Analyzing the dump file

If the file you are analyzing is a MiniDump, you can use dumpchk.exe from the Windows Support Tools.  For the other types, I use the Windows Debugging Tools.

Here’s how to set the dubugger up and use it to analyze the dump file.

1. Grab the Windows Debugging Tools from http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx and install them

2. Find the tools on your start menu (under All Programs..Debugging Tools for Windows)  and open WinDbg

Windows Debugger Symbol Path Dialog

3. In WinDbg, go to File and choose Symbol File Path.  Enter the following in the box:-

srv*c:\symbols*http://msdl.microsoft.com/download/symbols

and click OK to close

Analyzing the dump file

4. In WinDbg, go to File..Open Crash Dump.  Locate the MEMORY.DMP file you want to analyze and click Open.

Analyzing the dump file

5. The dump will be loaded and you will see the information recorded at the time of the crash.  To run a bugcheck analysis, type !analyze -v.

In this case, iostor.sys is the likely cause

6. Read the analysis, it will often be able to help you pinpoint the cause of the stop – look for the MODULE_NAME or IMAGE_NAME, PROCESS_NAME etc for clues.

This is especially helpful for tracking down problem drivers – if you find a driver is indicated as the cause, make sure you are running the latest version.   If you are, it may be worth contacting the vendor and providing your memory dump for analysis.

Each mailbox moved generates entries in the transaction logs for the source and destination storage groups, equivalent to the size of the mailbox – so if you move a 1GB mailbox, you can expect the logs to grow by up to 1GB.

Microsofts recommendation is to enable circular logging during mass mailbox moves.  To do this on Exchange 2007 via the Powershell, you can use the following command, putting the name of the storage group between the speechmarks.  You will need to dismount and re-mount each database, or restart the Information Store service, for the setting to take effect.

Set-StorageGroup -Identity "First Storage Group" -CircularLoggingEnabled $true

You can do this via the GUI, this is the way to do it via Powershell:-

Get-EventLogLevel – will return the current logging levels of the various Exchange components/processes

Set-EventLogLevel – to set the logging level for a specified component/process, e.g:-

Set-EventLogLevel MSExchangeTransport\SMTPSend  -Level High

Will set the logging for the specified process to High

If the name of the process you want to change the logging on has a space in it, for example

MSExchange Web Services\Core

the  you will need to put speech marks round it, like so

Set-EventLogLevel “MSEXchange Web Services\Core” –Level High

NOTE:Remember to turn the logging back down when you have finished troubleshooting!

Get-MailboxStatistics | where {$_.Lastlogontime -lt (get-date).AddDays(-90)}| Select displayName,LastLoggedOnUserAccount,LastLogonTime

You could also write the results to a csv using the Export-CSV cmdlet :-

Get-MailboxStatistics | where {$_.Lastlogontime -lt (get-date).AddDays(-90)}| Select displayName,LastLoggedOnUserAccount,LastLogonTime | Export-CSV c:\NoLogon30Days.csv

Many of the mailboxes are large (over 2GB), to keep user inconvenience to a minimum I’ve been running the moves overnight a few boxes at a time, using a simple Powershell script I wrote.

The script reads the alias of the mailbox to be moved and destination database from a CSV file.  I populate that file each evening with the details of the ones I want to move overnight, then kik the script off.  It logs sucess/failures to a text file which I check in the morning (it would be easy to modify the script to send this to you as a mail attachment using the Net.Mail.SmtpClient object in Powershell).

Here’s the script – to use it, save in your Exchange\Scripts folder as MigrateMail.ps, edit the $logfilepath and $sourcefile variables to suit, set up the csv and then run migratemail from a Powershell console.

#Mailbox migration script

#Oct 2009

#Set logfile location and filename
$LogFilePath = “c:\MailboxMoveLog.txt”

#Set source CSV location and filename
$SourceFile = “c:\MailboxesToMove.csv”

$users = import-csv $sourcefile

foreach($entry in $users) {
$mailbox = $entry.mailbox
$targetdatabase = $entry.targetdatabase
$error.clear()

$logmessage = “Moving Mailbox -> ” + $mailbox
Add-Content $LogFilePath $message

move-mailbox -Identity $mailbox -TargetDatabase $TargetDatabase -BadItemLimit 50 -PreserveMailboxSizeLimit:$true -Confirm: $false

#Sucessfull move action

if ($error.count -eq 0){
$logmessage = “Moved User Mailbox  ” + $Mailbox + ” Sucessfully”
Add-Content $LogFilePath $message
}

else

#Failed move action

{$logmessage = “Moved User Mailbox ” + $Mailbox + ” FAILED”
Add-Content $LogFilePath $message}
}