On older handsets I have been able to set the length of time the handset rings by manually choosing a length of time in seconds, usually in a settings menu. But, not on the iPhone. From what I can see, as of the iPhone 4 there is still no option to adjust the ringing time from anywhere in it's settings. Luckily, most service providers allow you to make these kind of user specific setting changes using service commands. To modify the length of time your handset rings before voicemail activates for any handset on o2, dial the following service command on your handset as though you are dialling a normal telephone number:

**61*901*11*XX#

Note: XX should be replaced by the time in seconds that you want the handset to ring for before voicemail activates. The value must be in multiples of 5 seconds. Values ranging from 05 to 30 seconds in length are acceptable. The default value is 15 seconds.

To turn voicemail on or off dial either of the following numbers:

Enable voicemail = 1750
Disable voicemail = 1760

I used the handset to attempt to open an PDF and surely enough I received the error:

This attachment type cannot be viewed on your device

Instinctively, I attempted to open a second and third PDF attachment, and even a Microsoft Word document just to make sure this wasn't a one off issue, it wasn't. I received the same error for all documents. Being unfamiliar with the OS of the BlackBerry handset I naturally began to look for an installed application that could be used to view the various attached documents, I couldn't find one. Comparing the applications list to a second fully functioning handset I noticed that the latter had Documents To Go installed. Using BlackBerry App World I installed Documents To Go but this still did not resolve the issue.

After some time pondering over the issue, I naively decided to update the firmware of the handset to the latest version assuming this would restore all applications and features. This had certainly worked for Nokia Symbian and Apple iOS devices bearing similar problems in the past. I downloaded the latest (v4.5.0.302 at the time of writing) BlackBerry Handheld Software for the Curve 8310 (service provider specific - Vodafone in my case) and used it to update the handset. Again, after performing an Enterprise Activation on the device with the BES server I was still unable to open attachments.

I went back to the list of installed applications on the faulty handset and again compared it to the fully functioning device. I noticed what appeared to be a BlackBerry specific application was also missing from the non functioning handset. A quick search revealed that the missing BlackBerry Attachment Service was required by the handset to process attachments that had been converted on the BES:

The BlackBerry Attachment Service receives attachments that are embedded in messages from the messaging server, through the BlackBerry Messaging Agent. The BlackBerry Attachment Service also receives attachments that are accessed through links in the BlackBerry® Browser.

I used the Application Loader feature from within BlackBerry Desktop Manager software to install BlackBerry Attachment Service back onto the handset. To my surprise I was still unable to view any attachments. It wasn't until after I erased the handset (using: Options --> Security Options --> General Settings --> Wipe Handheld) and then performed another Enterprise Activation that I was finally able to view attachments on the device through the BlackBerry Attachment Service.

Issue 1. Module exppw.dll could not be loaded

The first thing that struck me when I went to test OWA was that it wasn't working. I host a few websites on the same server so I was quite shocked to see that none of them were actually functioning. For what it was worth - I had already restarted the server so an IISRESET probably wouldn't have done much good. I decided to check the Application Event Log and saw this:

Source: IIS-W3SVC-WP
Event ID: 2282
Level: Error

Error: The Module DLL 'C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\exppw.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.

I also noticed the following warning in the System Event Log:

Source: WAS
Event ID: 5139
Level: Warning

Error: A listener channel for protocol 'http' in worker process '5436' serving application pool 'jjclements.co.uk' reported a listener channel failure. The data field contains the error number.

IIS was running, I could successfully Telnet into port 80 on the server. It appeared from the first (Application Event Log) error that IIS was trying to load a new module as part of the SP1 upgrade but couldn't. This was causing IIS to stop loading all of the sites that I had configured within it. I knew that since the release of SP1, Microsoft had released Update Rollup 1 to fix a few of the issues that SP1 brought with it. Out of best practice (and the hope that it may help my problem) I installed Update Rollup 1. Unfortunately it didn't resolve the issue.

Since the error was reporting an issue with IIS loading an x64 compiled module on x86 architecture I decided to investigate which website(s) was attempting to load the module. My reasoning for this was that by default, OWA runs in it's own application pool from a virtual directory located within the Default Website on an IIS installation. Although I had configured other application pools (for the other websites I am hosting) to run with "Enable 32-Bit Applications" set to True, the default setting of False still applied for the MSExchangeOWAAppPool application pool (so it seemed logical to assume that more than one website was probably trying to load the same module):

I used the IIS Manager to locate and then checked the web.config for the OWA virtual directory located:

C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\web.config

Sure enough there was an entry in the web.config for the site to load the exppw module, and because the MSExchangeOWAAppPool was correctly configured with "Enable 32-Bit Applications" set to False this was not the cause of my problem. Since it seemed that IIS was attempting to load the module for other application pools configured to run as 32bit (and I knowingly had other websites configured to run as 32bit) the next logical step was to check the main 'root' configuration file for IIS - applicationHost.config located:

C:\Windows\System32\inetsrv\config\applicationHost.config

The applicationHost.config file is used to store IIS configuration including sites, virtual directories, general settings, logging, caching etc. A quick search through this file revealed the exppw module was also being loaded globally (from within the <globalModules> tag):

<add name="exppw" image="C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\exppw.dll" />

I decided that I had a couple of options to fix this issue. The first was to stop IIS from loading the module globally by removing the entry from the applicationHost.config. I figured that this probably would have worked since the web.config for the MSExchangeOWAAppPool was loading it anyway. The second option I had was to make sure that the module was only ever loaded for an application pool when it's worker process architecture matched the architecture of the module that was being loaded. I chose the second option as I was concerned that modifying the applicationHost.config to prevent IIS from globally loading the exppw module may have caused issues if any of the other Exchange 2010 application pools were depending on the exppw module being loaded globally instead of from a local web.config.

IIS7 introduced the bitness32 and bitness64 preconditions to make sure that it will only load DLLs with the correct bitness in an application pool worker processes. Where specified, the bitness64 precondition is used by IIS to identify and then load modules only when the worker process is an x64 process - not if the worker process happens to be an x86 process.

I modified the applicationHost.config to reflect the bitness64 precondition for the exppw module:

<add name="exppw" image="C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\exppw.dll" preCondition="bitness64" />

Without even restarting IIS all of the websites that I host (including the Default Website and OWA application) started functioning again. The exppw module was now only being loaded where an application pool worker process was an x64 process.

Issue 2. Default Website additional bindings

While this didn't actually stop anything from working, the second problem that I happened to stumble across (when investigating Issue 1) was that the default website now had some additional, unconventional bindings:

It seemed that as well as the normal bindings allowing IIS to listen on ports 80 (http) and 443 (https) for all IP addresses on the server, the SP1 upgrade had added 2 additional bindings. Surprisingly, even though no host headers had been set, the additional bindings were also listening on ports 80 and 443 for the loopback address of 127.0.0.1. For consistency and just incase this caused any issues in the future, I removed the bindings. Seeing as no specific host headers were set for the new additional bindings I concluded that they would have been encompassed by the original 2 bindings anyway. A quick check revealed that none of my other websites had the additional bindings.

Issue 3. Incorrect HomeMTA attribute

Again, while this issue didn't actually appear to stop anything from working, the last problem I noticed was a consistent warning appearing in the Application Event Log. The warning was being generated at frequent intervals for each mailbox that I had configured within Exchange 2010:

Source: MSExchange ADAccess
Event ID: 2937
Level: Warning

Error: Process w3wp.exe () (PID=7276). Object [CN=James,CN=Users,DC=jjclements,DC=co,DC=uk]. Property [HomeMTA] is set to value [jjclements.co.uk/Configuration/Deleted Objects/Microsoft MTA
DEL:75830fde-6ed2-4fe2-b91c-005d7f6b1e6d], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.

A quick search revealed that the HomeMTA user account attribute was now obsolete for Exchange 2010. Yet, for some bizarre reason Exchange 2010 was obviously still checking that the value was valid (and unfortunately logging a warning in the Application Event Log if it wasn't.)

I used ADSI Edit to check the attribute for one my user accounts and confirmed it was set to the Deleted Objects container. Even though I don't have lots of Exchange users, rather than use ADSI Edit to update the HomeMTA attribute manually for each and every mailbox user I wanted to update them collectively. I had read that the Update-Recipient cmdlet could be used to update user account attributes, including HomeMTA. So, from the Exchange Management Shell, I used the Get-Mailbox cmdlet to retrieve all the user accounts with a mailbox in my single Exchange 2010 database and then piped the results into the Update-Recipient cmdlet. The following command successfully updated the HomeMTA attribute for all user accounts that had a mailbox in my Exchange 2010 database and stopped the warning from appearing in the Application Event Log:

get-mailbox -database "<databasename>" | update-recipient

Before hand, I decided to try a deployment on a test server just to see if I had any issues. The server is a single box that is also a Domain Controller. For testing purposes I also installed Exchange 2010 onto the same server. Initial installation and configuration was a breeze and I was soon sending and receiving email internally and externally. Upon investigation of some of the more granular Exchange configuration I soon had an issue when I tried to enable Recipient Filtering, there was simply no option to do so.

Recipient Filtering can be used for a couple of reasons. The first is to filter/prevent emails from being sent to specific email addresses that do exist within your organisation. The second is to prevent your email server from processing emails sent into your organisation to email addresses that do not exist. This typically happens in a couple of different situations when:

Scenario 1. A spammer targets 1000's of email addresses

• Spammer sends 1000's of emails with different FROM addresses (victim's addresses)
• Spammer sets the TO address as xxxx@yourdomain.com (non existent address in your organisation)
• Your email server receives and processes the emails but cannot deliver them to a mailbox
• Your email server replies to the 1000's of FROM addresses sending each 1 piece of NDR spam

Scenario 2. A spammer targets 1 email address 1000's of times

• Spammer sends 1000's of emails with a common FROM addresses (victim's address)
• Spammer sets the TO address as xxxx@yourdomain.com (non existent address in your organisation)
• Your email server receives and processes the emails but cannot deliver them to a mailbox
• Your email server replies to the FROM address sending it 1000's of pieces of NDR spam

Scenario 3. A spammer targets your email server

• Spammer sends 1000's of emails with different TO addresses (which won't exist in some organisations)
• Spammer sets the FROM address as xxxx@yourdomain.com (non existent address in your organisation)
• Recipient email servers send an NDR to the FROM address (non existent address in your organisation)
• Your server receives 1000's of pieces of NDR spam it then attempts to process and deliver

By enabling Recipient Filtering you make sure that if your email server does receive an email for an address that does not exist within your organisation it is blocked during initial SMTP communication. Recipient Filtering is by far faster and more efficient than evaluating the mail after it is received and already in the mail queue. This means that:

• Your server can no longer be used to send NDR spam to other email servers (Scenario 1 & 2)
• Your server will experience a reduced load if it comes under an NDR spam attack (Scenario 3)

The problem I had with Exchange 2010 was that I could not find where to configure Recipient Filtering! In Exchange 2003 it was configured under Global Settings --> Message Delivery. You then had to configure Advanced options on the SMTP Virtual Server and ensure the option for Apply Recipient Filter was applied. My Exchange 2010 installation did not have any such option(s) out of the box. It turns out the reason for this is that features of this nature are usually best suited to Exchange 2010 servers with the Edge Transport role installed. I attempted to modify the Exchange 2010 installation through Control Panel --> Programs and Features but the Edge Transport role was greyed out. An Exchange 2010 server with the Edge Transport role configured cannot have any other Exchange 2010 components installed, and since everything else was installed on my test server there was no way to enable the Edge Transport role.

After some searching around I found out that Recipient Filtering and a few other options like Sender ID are labelled as being Anti-spam features within Exchange 2010. I discovered that it is possible to install the Anti-spam feature (through the use of a PowerShell script) on an Exchange 2010 server configured with the Hub Transport role. This can be accomplished by:

• Open the Exchange Management Shell on the Exchange 2010 server
• Change directory into:
  

  C:\Program Files\Microsoft\Exchange Server\V14\Scripts

• Run the following to install the Anti-spam option:
  

  .\install-AntispamAgents.ps1

• Run the following to restart the Microsoft Exchange Transport service:
  

  restart-service msexchangetransport

• Open the Exchange Management Console and check that the Anti-Spam tab is available under Organization Configuration --> Hub Transport

Now that the Anti-spam features are available and enabled for use, I needed to make sure that the Recipient Filtering was configured. By opening the properties on the Recipient Filtering feature I could see that the option to 'Block messages set to recipients that do not exist in the directory' was not enabled. I checked this option to enable it as required.

A quick test using Telnet and the server was no longer receiving emails for addresses that do not exist in my organisation. Of course, doing this has a drawback. There would be nothing to stop a malicious user from using an automated tool harvest legitimate addresses within my organisation by sending email to random email addresses until successful. Fortunately, Exchange 2010 has Tar Pitting functionality enabled out of the box. Tar Pitting is the practice of artificially delaying server responses for specific SMTP communication patterns that indicate high volumes of spam or other unwelcome messages. By default Exchange 2010 delays the response sent to an email server (where an attempt is made to send to an address that does not exist in your organisation) by 5 seconds. Tar Pitting therefore makes directory harvest attacks too costly to automate efficiently. I personally think a 5 second delay is sufficient to thwart most directory harvest attacks, although the delay can be adjusted as necessary through the Exchange Management Shell on the Exchange 2010 server.

Run the following to retrieve the current Tar Pit interval in seconds:
Get-ReceiveConnector "Your Conector Name" | select tarpitinterval

Run the following to change the current Tar Pit interval (to 10 seconds in this case):
Set-ReceiveConnector "Your Conector Name" –TarpitInterval 00:00:10

Run the following to disable Tar Pitting:
Set-ReceiveConnector "Your Conector Name" –TarpitInterval 00:00:00

Here are the default devices for the Windows XP Professional VM:

Since I had built the 5 Windows XP VMs from a template I had created, I decided to find a way to convert the IDE disk to a SCSI disk and update the template incase I needed to resize the OS disk in the future. The easiest way I found to do this was as follows:-

Firstly I made the following assumptions:

• I would need to add a SCSI Controller to the VM and install the drivers before booting from the VMDK (I have seen cases before where moving a HD to new hardware caused a BSOD)
• If possible I would need to change the default Controller used for new VMDKs from IDE to SCSI
• I wanted to use the LSI Logic SCSI Controller
• I wanted to make the VMDK the first SCSI device (0:0) attached to the Controller

So, with the VM powered OFF I edited the settings for it through the VI Client and added a new SCSI Device (by default it doesn't seem possible to simply add a SCSI Controller to a VM without also attaching a SCSI Device to it):

I left the SCSI Device as being a CDROM and (optionally) changed the Virtual Device Node to SCSI (0:1) so that when I converted the existing disk and added it to the SCSI Controller it would be device SCSI (0:0). I clicked Next and Finish but I didn't click OK to commit the changes:

Before clicking OK, I selected the SCSI Controller and changed it's type as appropriate. Then I clicked OK to commit the changes to the VM:

I powered on the VM and noticed that the Windows Found New Hardware Wizard prompted me to install the driver for the SCSI controller. I knew that the controller used is a LSI20320-R so I downloaded it from here:

LSI20320-R - Driver Download (Click the Support and Downloads tab)

I downloaded the appropriate driver and extracted it (for Windows XP 32bit I used LSI20320-R_xp_50700_01034132IT_1201800_1005239.zip and within that symmpi_wXP_1201800.zip.) Then I used the Found New Hardware Wizard to browse for and install the driver. Once the hardware installation completed I shut down the VM. The VM now had the SCSI controller installed and I was confident I would be able to boot from it.

I then located the datastore where the VM resides. For example:

/vmfs/volumes/<datastore>/<vm>/

You can use the Service Console or an SSH\SCP application to open the <vm>.vmdk (not the <vm>-flat.vmdk). I edited the following line:

ddb.adapterType = "ide"

For the LSI SCSI Controller I changed it to:

ddb.adapterType = "lsilogic"

After saving the file I used the VI Client to edit the VM settings. I selected the IDE disk and removed it. I then clicked OK to commit the changes.

NOTE: Remember to only 'Remove from virtual machine' and NOT 'Remove from virtual machine and delete files from disk':

Then I used the VI Client to edit the VM settings again and add the disk back. This time, because I had edited the .vmdk file to specify that the disk uses the LSI Logic Controller, it attaches the disk to this instead of the IDE Controller used previously:

The disk is added as device SCSI (0:0):

I clicked Next and Finish to complete adding the disk. I then selected the CDROM (SCSI device 1) and removed it:

I clicked OK to commit the changes to the VM. I now had a VM using the LSI Logic SCSI Controller with the System OS disk connected to the Controller as device SCSI (0:0).

Since the VM had already booted with the LSI Logic Controller installed, when I powered on the VM Windows booted normally and was immediately accessible. Subsequently, any new virtual disks created for the VM are automatically created as SCSI disks and attached using the next available Virtual Device Node.

When I checked the Application log in the event viewer I was presented with the error:

Source: Active Server Pages
Event ID: 5
Level: Error

Error: File <url to upload.asp> <line number> Operation not Allowed.

The error indicated that there was an issue with the ASP configuration for the website hosting the application so I had a quick look at the ASP settings in the IIS Manager:

In the settings for ASP I noticed the following option:

Limits Properties --> Maximum Requesting Entity Body Limit

The default value for this property is 200000 bytes which is just under 0.2 megabytes. The file I was trying to upload was just over 3 megabytes so I needed to increase this value. I changed it to 10485760 bytes which is 10 megabytes. Upon retrying to upload the document through the ASP application I was successful. No restart of IIS was necessary.

Selecting the Custom (advanced) option allowed me to remove existing partitions and install Windows 7 as I would have expected to out of the box, instead of having to perform a Vista to Windows 7 upgrade. After successful installation of the OS I installed the remaining drivers and then tried to activate. During the activation process I was prompted with an error.

The following failure occurred while trying to use the product key:

Code:
0xC004F061

Description:
The Software Licensing Service determined that this specified product key can only be used for upgrading, not for clean installations.

To activate Windows 7 after I used the upgrade disc to perform a clean installation I changed one registry key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\OOBE

Value: MediaBootInstall= 1 changed to 0

After modifying the registry key I was able to activate successfully.

Download the regkey change - HERE

As far as W32Time (the Windows time service) is concerned, at the topmost level within the domain is the domain controller on which the PDC Emulator Flexible Single Master Operation (FSMO) role resides. This can be configured to synchronize it's time with a reliable external time source. By default all other domain controllers internally synchronize their time with the PDC Emulator. Similarly all domain member client computers synchronize their time with the domain controller that authenticates them.

Configuring the domain controller where the PDC Emulator role resides should be the only computer in the domain that requires any manual intervention to have the precise time on all domain client computers.

To find out which server the PDC Emulator role resides on open the Active Directory Users and Computers (ADUC) snap-in. Then right click on your domain and select 'Operations Masters'. Browsing the PDC tab will show you where the PDC Emulator role currently resides.

On the domain controller where the PDC Emulator resides you can configure it to synchronize its time with an external source by using the following command:

net time /setsntp:<ip/dns>

Use the following example to set multiple external time sources to sync with:

net time /setsntp:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org"

You can also configure this manually by modifying the following registry key:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

NtpServer=<ip/dns>
Type=NT5DS change this to Type=NTP

After making the above changes restart the W32Time service by issuing the following commands at a command prompt:

net stop w32time
net start w32time

NOTE: If you don't configure the PDC Emulator to synchronize its time with an external source it will simply use its own (CMOS) clock. Doing so will occasionally cause an error to appear in the event log on the server that resembles the following:

Event Type: Error
Event Source: W32Time
Event Category: None
Event ID: 12

Event description: Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source.

NOTE: If you experience a client with time synchronization problems ensure that it has the correct time zone set. If needed, the time service can be reset using the following commands:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /resync

After some investigation I realised that when VCB performed a dump of the VMDK it was correctly dumping the used space. It then dawned on me that when Windows was deleting files from the disk it was actually only deleting the 'pointer' to the data and not the data itself. When VCB was dumping the VMDK it was correctly dumping all blocks of the disk that contained data. I then started looking for a way to clean blocks that were no longer being used but still contained remnants from deleted files. I found a tool called SDelete that writes zero's where the disk contains free space as seen by the Operating System.

I incorporated SDelete into a basic script that also uses Defrag (the Windows utility for defragmenting disks) to tidy up volumes and potentially reduce the size of backups when using VCB.

The script first enumerates all local drives on the VM. For each drive that Windows deems as being a local disk the script then defragments the volume and uses SDelete to zero any free space that the disk may have. The script is written in KiXtart.

Here is the script:

;=====================================================
;=====================================================
;
; ENUMERATE LOCAL DRIVES - DEFRAG & ZERO EMPTY BLOCKS
;
;=====================================================
;=====================================================

;=====================Accept EULA=====================
WriteValue("HKCU\Software\Sysinternals\SDelete", "EulaAccepted", "1", "REG_DWORD")

$Drives = GetObject("winmgmts:").ExecQuery("select Name,DriveType from Win32_LogicalDisk")

For Each $Drive in $Drives

If $Drive.DriveType = 3

SHELL "%comspec% /c " + chr(34) + "defrag.exe " + $Drive.name + " -f" + chr(34)
SHELL "%comspec% /c " + chr(34) + "sdelete.exe -c " + $Drive.name + chr(34)

EndIf

Next

;=====================================================

I use this by placing the folder CleanDisk (download link below) in C:\Program Files. I create a Windows scheduled task to run either KIX32.exe or WKIX32.exe on say a monthly basis.

NOTE: If you have multiple VMs with VMDKs residing on the same physical storage you will probably want to consider staggering the schedules to reduce I/O on the physical disks.

Download the script and necessary files - HERE

1) Open iTunes and navigate through the menu to: Edit --> Preferences --> Advanced (tab)

2) Click the change button and change the folder location to something like D:\My Music (you will need to create this folder.) Click OK to close the screen.

3) Close iTunes altogether.

4) Copy your iTunes folder from C:\Documents and Settings\(username)\My Documents\My Music to D:\My Music.

5) Hold down the SHIFT key and click the iTunes shortcut.

6) Click on Choose Library (to point iTunes to the new library) and browse to D:\My Music\iTunes\iTunes Library.itl. Once you have selected the file iTunes Library.itl click Open.

7) Once you have opened iTunes using the library in the new location of D:\My Music\iTunes you can remove the old copy located in C:\Documents and Settings\(username)\My Documents\My Music.