Search This Blog

Tuesday 25 June 2013

Mirroring iSCSI Volumes with Dynamic Disks (Windows Server 2008R2/2012)

Problem

I was recently tasked with copying a raw iSCSI LUN from one SAN to another within a window of an evenings downtime.

No problem I initially thought, I can present both LUNs to a single server and run an XCOPY/ROBOCOPY job to copy all of the data across. I later found there to be two problems with this plan:

  • A copy job containing 7TB of data would not complete in one evening.
  • There was a fairly large amount of files with long file names sporadically nestled in the file system which would cause the copy job to fail and require babysitting.
Solution

A colleague suggested that I could overcome the above issues by mirroring dynamic disks and then breaking the mirror once the synchronization had finished. That way users can still access the files via the source data whilst the disks are syncing and as it's done on a block level we no longer have to worry about any files with long files spoiling our fun.

First present both disks to a single server and convert the source to a dynamic disk:

Right click the source volume and add a mirror:

Choose your target disk:


Accept that the target disk will be converted to a dynamic disk:


Wait until the disks have finished syncing and show healthy:


Right click one of the mirrored volumes and choose 'Break Mirrored Volume':

Offline the source disk and change the drive letter to resume that place of the source (in my example drive E:):

Disconnect the source disk and start using your new volume:


At the time of writing this I could not find this procedure documented online, so I hope it has been helpful to any of you reading.

Monday 24 June 2013

451 4.4.0 Primary target IP address responded with: "451 5.7.3 Must issue a STARTTLS commnd first" Office 365 Hybrid


If you have an Office 365 hybrid configuration you may experience issues sending emails between on premise and cloud users (in either direction).

The Exchange 2013 (or 2010) on premises queue viewer may show:

'451 4.4.0 Primary target IP address responded with: "451 5.7.3 STARTTLS is required to send mail." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts. The last endpoint attempted was xxx.xxx.xxx.xxx'

The Office 365 Message Trace Console shows the delivery status of 'None'
 

Office 365 Message Trace
 





The errors suggest the TLS connection cannot be made but a TLS certificate IS present and during the Hybrid Connection Wizard the required connectors are automatically created so should not require an additional configuration.

When an email is sent between on premise & cloud (Office 365) users of your SSO domain it is sent across one of the automatically created send connectors. These connectors are secured using TLS.

So, assuming you have ruled out all the normal stuff its now time to get baffled. We know the on premise server can send and receive external email. We also know that the Office 365 service can send and receive email. It is just the email between the two services that does not work.

I was banging my head against a wall for ages until I used Telnet to connect from my on premise Exchange server to Microsoft cloud gateway.

What I got is shown below:





This is not correct. As you can see the server has not recognised the "ehlo" statement and the banner does not "look right"...

A bit of digging around the firewall I noticed that packets were being dropped when TLS was attempted.

The firewall is a Cisco PIX 515. I disabled ESMTP inspection but that made no difference so I discounted this as the cause.

After a lot more digging around and raging I remembered that the PIX was behind another Cisco firewall - this time an ASA 5510. So I accessed this device and sure enough this edge firewall was also inspecting and dropping TLS over SMTP.

Once both firewall were configured not to inspect ESMTP the default configuration that was set by the Hybrid Configuration Wizard started working straight away.

The commands to disable ESMTP inspection are:

pix(config)#policy-map global_policy
pix(config-pmap)#class inspection_default
pix(config-pmap-c)#no inspect esmtp
pix(config-pmap-c)#exit
pix(config-pmap)#exit

Or you can do this via the ASDM GUI as shown.














Now telnet the cloud server and you should see a correct banner: