Apple release iOS 6.1.1 to fix one bug but it doesn’t fix the bug with Exchange

After Apple released iOS 6.1 on the 28th January 2013, numerous people have complained of various issues with 3G connectivity, others have complained about battery life being reduced dramatically and more recently, Exchange servers around the world have been slowing down due to what appears to be a problem with the devices looping when Calendar Appointments are accepted on the iPhone / iPad.

Today Apple has released iOS 6.1.1 (only for the iPhone 4S) which seems to address the 3G issues, but it doesn’t fix the Exchange issues and Microsoft / Apple are working together on the problem to see if it is an Exchange issue or an Apple issue.

So whilst some can upgrade, not everyone can and even those that can upgrade, may well have to upgrade yet again when a new update is released that fixes the Exchange issue.

Exchange Admins all over the world are probably restricting access to their Exchange Servers for those who have upgraded to iOS 6.1 until they delete and re-create their Exchange Accounts and promise not to do anything with Exchange Calendar Appointments (in terms of Accepting / Declining etc). Once they have deleted and added their account back, the Admins may allow them back on the server as this is rumoured to ease the performance issues that the Exchange servers are suffering.

The iOS 6.1.1 release is 968Mb in size, so it isn’t a small download. If you are not suffering from battery / 3G issues, you may as well wait to see if there is a newer release and download that instead.

I for one (with my iPhone 4S), have only just upgraded to iOS 6.1 but won’t be updating to iOS 6.1.1 because I can’t face the hassle of Jailbreaking it all over again and re-install/configuring my Jailbroken apps so recently after Jailbreaking iOS 6.1, only having to do it again when 6.1.2 or 6.2 (or whatever comes next) is released to fix the problem, assuming it lies with Apple and not Microsoft.

Watch this space for more news as and when it becomes available.

Alan

Exchange 2010 – Cannot login after mailbox has been disabled and attached to different AD user account

I was asked to rename an Exchange account (sitting on an Exchange 2010 SP2 server) for a customer today because the surname had changed so to do this tidily, I disabled the Exchange Mailbox, cleaned up the Databases to make the mailbox appear in the Detached Mailboxes folder using the following Exchange Management Shell command:

get-mailboxdatabase | clean-mailboxdatabase

Once that had run, I then deleted the AD user account, created a new AD user account and then Connected the Detached Mailbox to the new AD user account.

All done – I then informed the user of the new login credentials and they then setup their Outlook account accordingly.

It was then that the problem occurred.  They couldn’t login to their account.  They tried OWA and that failed too, saying that the account was disabled!  What the heck?

I tried using OWA and also got Account Disabled and saw the following error message when expanding the error:

Exception type: Microsoft.Exchange.Data.Storage.AccountDisabledException

I checked the AD account and it wasn’t disabled.  Forced an AD Replication and that made no difference.  I disabled the account – replicated AD – enabled the account – replicated AD again and still couldn’t login to OWA.

After a few checks and some head scratching, I re-ran

get-mailboxdatabase | clean-mailboxdatabase

and then was able to login to OWA as the user and they could login to Outlook.

 

SBS 2003 to SBS 2011 Migration Performed Remotely in Toronto Canada (from the UK)

Last night I started to perform a migration from SBS 2003 to SBS 2011 for a company in Toronto where Peter was going to be onsite to manage the migration from the local end.

The start time for me was 9:00pm (UK time) and prior to starting, I had asked Peter to make sure the SBS 2003 server was fully patched, had the Microsoft Baseline Configuration Analzyer tool installed (and to reboot the server afterwards), check that Exchange 2003 Service Pack 2 was installed and also that Small Business Server 2003 SP1 had been installed properly, something that quite often doesn’t get installed properly as it isn’t a simple download from Microsoft via Windows Update.

I also asked Peter to run a DCDIAG report (after installing the Windows Server 2003 Service Pack 2 32-bit Support Tools) to make sure that all was well and email me the results

The only item that needed fixing from the DCDIAG report was to set the Intersite Messaging Service to Automatic and Start the service, something that is quite often not set to Automatic on SBS 2003 from my experiecnce.

All being well, it was time to start the migration.  I asked Peter to insert the SBS 2011 DVD into the SBS 2003 server and then once fired up, we installed the Migration Preparation Tool (without installing any updates).

The SBS 2003 server was prepared happily, the Migration Answer File created and saved to a Memory Stick (USB Key) and then the server was rebooted.

It was then time to build the new server, and Peter had chosen an HP ProLiant DL360 G7 server (nice!).  To cut a long story short, there were a few problems with the build and after referring him to my other blog article here he happily created a bootable USB key with SBS 2011 on it and then rebuilt the server for a second time, this time more successfully.  Also on the USB Key with SBS 2011 as an .ISO image were the drivers for the RAID Controller and the SBS Answerfile.

After a few reboots and having changed the boot order so that the server would no longer boot from the USB Key after the initial Windows build, the server fired up into Migration mode and the Migration could start.

The settings chosen in the SBS Answer file were checked and verified, the Time Zone checked and verified (important to do this manually as the BIOS clock can be way off) and updates were not downloaded for the installation.

After a while, the server rebooted and we were logged in to the SBS 2011 server.  Time to create a new User as the Migration won’t work if you use the default Administrator account.

After the new Admin Account was created we logged off, then on again as the new user and fired up the SBS Console and clicked on the Migrate to Windows SBS link on the Home page.

Having created just a single partition, the first step of relocating the various components of SBS to another drive was skipped and we moved on to the Configure the Network Wizard.  With nothing much to do there apart from click a few buttons (DHCP was not on a router), the wizard completed and we moved onto the next step.

Configuring the Internet Address we selected the relevant domain name and changed the default prefix of ‘Remote’ to a preferred name and completed the wizard.  This failed initially and threw a few errors.  After a few minutes of head scratching and wondering why, I checked the Services and found a handful of Exchange ones not started!  After a bit of encouragement with my mouse, the services were started and the Wizard re-run, this time 100% happily.

At this point, it was time to pause the installation and visit Windows Update.  It was now about 5:40am (UK time) and caffeine had been working happily, but you need to draw the line somewhere and get some sleep, so having selected about 133 Windows Updates and kicked the updates off, I retired to bed as the world was waking up and the light outside was getting lighter 😦

We are planning to pick up the Migration again at 3:00pm UK time today and at the time of writing I am remotely connected to the server and busy installing a raft of other updates that are available and rebooting as and when required.  I have now done this about 3 times and the cupboard is now well and truly bare, so time for more caffeine and to wait for Peter to arrive on-site and then order the SSL certificate from www.exchange-certificates.com and get it approved before moving the mailboxes from the SBS 2003 server to the SBS 2011 server.

So, Peter arrived on site and we order a new SSL certificate from the site above, ran the New Certificate Wizard in the Exchange Management Console to generate a Certificate Signing Request (CSR), took the CSR to the certificate site and copied / pasted the contents into the relevant box and completed the certificate request process.  Now we just had to wait for the approval emails to arrive.  Prior to starting the migration, I had asked Peter to make sure that the Admin contact for the domain was still valid and that he had access to the email account that the Certificate Approval emails would be sent to – he was the Admin contact and thus we wouldn’t have any problems receiving and processing the Certificate Approval emails.

The next step in the migration was to move the mailboxes over from the old server to the new server and that is done via the new server using a “Local Move Request”.  We essentially highlighted all the User mailboxes and then clicked on the New Local Move Request.  We actually selected a few large mailboxes first and then the remainder which were smaller so that the larger ones started to be moved first.

Next was to move the Public Folders and that was simply a case of right-clicking the Public Folder Store and choosing “Move All Replicas”.  There weren’t many Public Folders so I expected this to be a quick process, but after an hour or so of watching the mailboxes move, the Public Folders hadn’t even started to move, so I checked the the SMTP Virtual Server settings and lo and behold, there was some Outbound Authentication that was set because they had previously setup a Smarthost on the SMTP Virtual Server (which I had already removed).  As soon as I removed the outbound authentication and restarted the SMTP Virtual Server, the Public Folders started to move over to the new server and after about 5 minutes, the Public Folder Instances were all empty 🙂

Next was to remove Legacy Group Policies and Logon Settings which essentially is the deletion of old SBS 2003 Group Policies and renaming the SBS_LOGON_SCRIPT.BAT file and removing references to it from ALL user profiles.

The next step in the migration was to setup a batch file to use Robocopy to copy all the User / Company data from the old server to the new server.  I looked at the shares on the old server and didn’t see anything that stood out as a Company Data folder, so asked Peter to identify the relevant data, which he did and I setup the batch file to copy the data he had identified as well as the User Data, which was obvious.

I decided to kick off the data copy batch file (run as Administrator) and then all we could do was sit and wait, so I suggested to Peter that he might like to go and have an extended lunch break and that I would monitor the Mailbox Moves and data copying remotely, then let him know when it was likely to have completed, so he could return to help with the final steps in the migration.

I emailed Peter and arranged for him to return to the office at 8:00pm Toronto time (1:00am UK time).  All the data and mailboxes had moved across by about 1:40am UK time so the next step was to Migrate Fax Data of which there wasn’t any, so we moved on to the next step which was to convert Users and Groups.  All users were assigned the new Standard User role and all Groups were selected and converted – all very simple stuff and quick to perform and by now, the finishing line was in sight.

Before removing Exchange 2003 from the SBS 2003 Server it was time to redirect port 25, 443, 987, 4125 and any other ports being used on the firewall to the new server.  Once completed, I could then remove the Routing Group Connectors that are installed to allow mail to flow between the Exchange 2003 and Exchange 2010 servers during the migration.

It was now time to remove Exchange from the old server by using the Add/Remove Programs, selecting the Small Business Server 2003 application and then running through the various screens until the installed options were visible, then setting Exchange to ‘Remove’ and finishing the wizard.  This process never normally removes exchange fully (in my experience), so I had to refer to an MS KB Article to manually remove the remaining components of Exchange (KB833396).

The final step is to run DCPROMO, but before we do, it is a good idea to check that the SBS 2011 Server is the holder of all FSMO roles.  I found a little file that allows me to do this without having to break sweat – don’t recall where it came from, but I am grateful to the creator.  You can download it from here dumpfsmos.zip.  Having run and verified that my FSMO roles were all held by the SBS 2003 server, I fired up DCPROMO and let it run, making sure I didn’t tick the box that says “This server is the last controller in the domain” as that would cause all kinds of havoc.

For some odd reason – every time I run this the first time, it always fails because the NETLOGON service has been stopped and it complains about it being stopped.  Well the DCPROMO process stops the NETLOGON service, so I am not sure why it gets confused, but it always does, so prepare for it to fail, then start the NETLOGON service up again and re-run DCPROMO again which on the 2nd time of running, will happily complete.

Once done, reboot the server, then login to the local server as the Administrator, using the password you specified during the DCPROMO process and once it is alive, shut it down and keep it handy in case you forgot to get some data from it.  MIGRATION COMPLETED!

The time that the migration was finished was about 3:30am UK time, so from start to finish, the entire process took about 30½ hours, but it has to be said that there was little data to be copied and the mailboxes were small.

The article that I used to guide me through the entire migration, which I will be asking Glen to tweak slightly with some items to make it even better than it is already can be found here.

If after reading it you don’t feel confident enough to tackle the migration yourself, I would be only too happy to assist you.  If you do feel confident enough then I hope your migration goes smoothly and completes quickly.

Alan

SBS 2003 to SBS 2011 Migration – 50Gb of Public Folders to Migrate took a week to migrate!

Having nearly completed yet another SBS 2003 to SBS 2011 Migration after the longest week of my life so far, I was amazed at how slowly the Public Folder Replica Move actually took to push 50Gb of data between the two servers.

Starting the project on a Monday and having the SBS 2011 server built by Monday afternoon (built virtually using Microsoft’s Hyper-V Server on a new HP ProLiant ML350 G6), I started to move the Exchange Mailboxes and then the Public Folder Replicas to the SBS 2011 server.  The network was originally running on a 10/100 Switch but I upgraded it to a Gigabit Switch on the Tuesday morning so that I had the maximum speed available and both servers had Gigabit cards in them.

At the end of the Tuesday, there were still dozens of Public Folders listed in the Public Folder Instances list in the Exchange System Manager, so I checked the SMTP Virtual Server Settings to see if there were any settings configured that might slow the process down and discovered several settings that would restrict the flow of emails.  The initial setting that I noticed was the “Limit session size to (KB):” setting.  This was limited to 40Mb and as some of the emails in the Public Folders were in the region of 30-40Mb in size, the session size was going to severely impact the flow of mail so I changed it to 1024000 (about 1Gb).

The other setting that I changed was the “Connection Timeout” value on the General Tab.  This was set to timeout after 10 minutes, so I increased the timeout to 2 hours, so that this wouldn’t cause any delays either.

I wasn’t unduly concerned at this point about problems with inbound mail and spammers clogging up the system as I had already installed a SAN/UCC SSL certificate (minimum 5 Domain Names) bought from www.exchange-certificates.com and had re-pointed port 25 to the SBS 2011 server.

So having made as many changes to the network and SMTP Virtual Server Settings (also restarting the Simple Mail Transport Service) I created a new Receive Connector on the SBS 2011 server to only receive mail from the IP Address of the SBS 2003 server and set the Maximum Message Size Limit to 50Mb and let the two servers talk to each other.

Sometime overnight on the Saturday after starting the migration, the whole 50Gb of Public Folders had migrated across to the SBS 2011 server and all the Public Folder Instances had disappeared!  A whole 5½ days later.

At one point during the PF Replication, I calculated that it was moving at about 500Mb per hour, so all in all, it was going to take in the region of 100 hours to move the entire database.

So – if you are planning a migration from SBS 2003 to SBS 2011 and you have a large Public Folder Database, don’t expect the migration to complete quickly.  Assuming the worst – a Public Folder Database with 75Gb of data in it, I would expect it to take about a week and a half just to push the data to the new server.

Happy migrating!

Users Connecting To Exchange 2010 (SBS 2011) Using Outlook 2010 Getting Password Prompts Randomly

I had an email from a customer recently who has an SBS 2011 server (with Exchange 2010) running virtually on an HP Proliant ML350 G6 server (which I had installed for them) and they were reporting that a couple of users were getting password prompts at random times.  This wasn’t affecting all users, so I knew it wasn’t a server-side issue, especially because I installed a trusted 3rd party SSL certificate from www.exchange-certificates.com so asked a few questions and it seemed that this only happened after the machines had been left idle for a while.

My initial thoughts were that there might be some issues with the Network Card having Power Management enabled on it which allowed the PC to turn off power to the NIC to save energy, so I asked my customer to check the NIC settings and sure enough, the Power Management setting to “Allow the computer to turn off this device to save power” was enabled.  After disabling this option, the problem went away and has not returned.

Having had someone ask a similar question on http://www.experts-exchange.com and the solution being the same, I felt it rude not to share this discovery so that others might benefit from this discovery.

To disable this option, click on Start> Run> {type} ncpa.cpl {and press enter}, then right-click on your Wired / Wireless Network Card and choose properties.

On the Network Card Properties, click on the Configure Button (see image below)

then click on the Power Management Tab (see image below)

and make sure that the “Allow the computer to turn off this device to save power” check box is not ticked.

Once you no longer have the computer turning off the power to the network card, it shouldn’t lose connectivity to the server and thus won’t be prompting you for your credentials when you go to use Outlook again.

 

Schedule a Transport Rule to be Enabled or Disabled at a Specific Time of Day / Day of the Week

The Problem:

In Exchange 2003, you could configure Exchange to delay the sending of large attachments until after hours, which was very useful if you have users that don’t think twice before creating an email and attaching dozens of their most recent photographs in the email, then adding 20 or 30+ recipients to the email and hitting send – causing your Exchange server to go into melt-down as it tries its best to push all the emails out as quickly as possible.

So – having upgraded to Exchange 2007 or Exchange 2010 you may have discovered that this options doesn’t exist any more, so you may find from time-to-time that your Internet connection suddenly grinds to a halt and if you dig hard enough, you may find the problem is sitting in your outbound Queues on your Exchange Server.

So – what to do about this?

Half a Solution:

You can create an Exchange Transport Rule to force large emails to be approved (before they are sent out), by a Manager or a Moderator which at least enables the Manager / Moderator to have to Approve the email before they clog up the Exchange Queues but as we are now living in a 24×7 age, if you don’t want to have to approve / reject the emails in the evenings or over the weekend, there is no option in the Transport Rule to schedule the times that the Rule applies!  Quite frustrating, especially over a long weekend.

The Whole Solution:

The answer (well, my answer) to this is to create two Powershell Scripts, two batch files and a two Scheduled Tasks to Enable / Disable the Transport Rule at specific times (Disable after hours on Weekdays / Enable before work starts on Weekdays).

Start by creating a new folder on your Exchange server called Scripts on any drive you like (I will be using E:\scripts in my example).

Then open up Notepad and copy / paste the scripts below (one script per file) and then save the files as DisableTransportRule.ps1 and EnableTransportRule.ps1 in the E:\Scripts folder.

The PowerShell Scripts:

Disable Transport Rule:

# Script to Disable a Transport Rule
Disable-TransportRule “Rule_Name” -confirm:$false

Enable Transport Rule:

# Script to Enable a Transport Rule
Enable-TransportRule “Rule_Name” -confirm:$false

The Batch Files:

Open up Notepad and copy / paste the single line commands below (one command per file) and then save the files as DisableRule.bat and EnableRule.bat in the E:\Scripts folder.

Disable Transport Rule Batch File:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1’; Connect-ExchangeServer -auto; e:\Scripts\DisableTransportRule.ps1”

Enable Transport Rule Batch File:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1’; Connect-ExchangeServer -auto; e:\Scripts\EnableTransportRule.ps1”

Scheduled Tasks:

Open up Server Manager and Expand Configuration> Task Scheduler.  In the Actions Pane, click on Create Task…..

 

On the General Tab, Name the Task according to the rule you want to run e.g., Disable Transport Rule, then Select ‘Run whether user is logged on or not” and “Run with highest privileges”.

On the Triggers Tab, Click on New and Select “Weekly” and enable the days of the week you want the rule to run e.g., Mon to Fri.  Set the time you want the rule to run e.g., 18:00:00 hours and tick the “Enabled” box and click OK.

On the Actions Tab, Click on New and the default option is to Start a Program.  Leave this selected and in the Program/script: window, click on Browse and select ‘e:\scripts\disable.bat’, then in the Start in (optional): box, enter ‘e:\scripts’ and click on OK.

We don’t need to add anything to the Conditions Tab or the Settings Tab, so click OK and then enter the relevant username / password for the account you want to use to run the Scheduled Task as (usually an Administrator account).

Repeat the above for the Enable.bat file.

One last step:

Before these commands will run properly, you need to run the following command in the Exchange Management Shell:

Set-ExecutionPolicy RemoteSigned

This command allows Powershell to interact with the Exchange Management Shell.

Summary:

So – you should now have two Scheduled Tasks that Disable your Transport Rule at a specified time on specific days (mine are Disabled at 18:00:00 hrs Mon – Fri) and another Scheduled Task to Enable the Transport Rule at a specific time one specific days (mine are enabled at 07:30:00 hrs Mon-Fri), so now, after hours and at weekends, you won’t have to approve emails for your Exchange organisation and if someone sends out an email with large attachments to multiple users, there is less impact on the rest of the workforce.

Alan

Exchange 2007 & 2010 SSL Certificates

Having just installed Exchange 2007, Exchange 2010, SBS 2008 or SBS 2011, you are now probably at the stage of getting Exchange to work properly (Activesync, OWA, Outlook Anywhere and Autodiscover) and are debating whether or not to use the self-issued SSL certificate installed with the version of Exchange you have, or buying a 3rd party SSL certificate.

Well, for me – it is a no-brainer. I ALWAYS buy a 3rd party SSL certificate from www.exchange-certificates.com because I can buy one, request the certificate, approve the certificate, import it onto the server, enable it for SMTP, POP3, IMAP and IIS and then forget about it for at least 3 years (I always buy one for 3 years minimum) until it is time to renew the certificate.

Once the SSL certificate has been imported and enabled, ALL aspects of Exchange will work (Activesync, OWA, Outlook Anywhere and Autodiscover) and there won’t be any annoying popups in Outlook complaining about certificate issues.

With Exchange 2007 / 2010, the following names should be included in your SSL certificate:

mail.externaldomain.com (or whatever you prefer to use)
autodiscover.externaldomain.com
internalservername.internaldomain.local
internalservername

With SBS 2008 / SBS 2011 you should include the following names:

mail.externaldomain.com (or whatever you prefer to use)
autodiscover.externaldomain.com
internalservername.internaldomain.local
internalservername
sites

You will also need to setup a new A record in your Domains DNS records (external via your Domains Control Panel, not in your internal DNS records) called Autodiscover and this needs to point to the IP Address of your Exchange / SBS server.  If you can’t do this (and sometimes this is not possible), the alternative it so setup an SRV record and the following MS guide advises you how to achieve this:

http://support.microsoft.com/kb/940881

With Exchange 2003, a simple single name certificate was all that was required and these were much cheaper than the SAN (Subject Alternative Name) / UCC (Unified Communications Certificate) certificates, but sadly, these sort of certificates won’t work properly with Exchange 2007 or 2010.

Whilst some parts of Exchange 2007 and 2010 can be made to work without a 3rd party SSL certificate by tweaking the settings in Exchange, my personal recommendation is to save yourself the pain of doing so by spending the small amount of money it takes ($60 / £40 per year) and save yourself the hassle of trying to tweak Exchange and get all the settings correct. This can be time consuming (how much is your time worth to your company) and fiddly to say the least and the time spent / cost of fixing Exchange to make it work with the self-issued SSL certificate vs the small cost of buying and installing a SAN / UCC certificate is money well spent in my humble opinion.

Extract from Understanding the Self-Signed Certificate in Exchange 2007 :

Limitations of the Self-Signed Certificate

The following list describes some limitations of the self-signed certificate.

• Expiration Date: The self-signed certificate is valid for one year from the date of creation in versions of Exchange 2007 that are earlier than Exchange 2007 Service Pack 2 (SP2). Self-signed certificates are valid for five years from the date of creation in Exchange 2007 SP2 or in later versions. When the certificate expires, a new self-signed certificate must be manually generated by using the New-ExchangeCertificate cmdlet.
• Outlook Anywhere: The self-signed certificate cannot be used with Outlook Anywhere. We recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party if you will be using Outlook Anywhere.
• Exchange ActiveSync: The self-signed certificate cannot be used to encrypt communications between Microsoft Exchange ActiveSync devices and the Exchange server. We recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party for use with Exchange ActiveSync.
• Outlook Web Access: Microsoft Outlook Web Access users will receive a prompt informing them that the certificate being used to help secure Outlook Web Access is not trusted. This error occurs because the certificate is not signed by an authority that the client trusts. Users will be able to ignore the prompt and use the self-signed certificate for Outlook Web Access. However, we recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party.

Extract From Exchange 2010 Understanding Digital Certificates and SSL :

Self-Signed Certificates
When you install Exchange 2010, a self-signed certificate is automatically configured. A self-signed certificate is signed by the application that created it. The subject and the name of the certificate match. The issuer and the subject are defined on the certificate. A self-signed certificate will allow some client protocols to use SSL for their communications. Exchange ActiveSync and Outlook Web App can establish an SSL connection by using a self-signed certificate. Outlook Anywhere won’t work with a self-signed certificate. Self-signed certificates must be manually copied to the trusted root certificate store on the client computer or mobile device. When a client connects to a server over SSL and the server presents a self-signed certificate, the client will be prompted to verify that the certificate was issued by a trusted authority. The client must explicitly trust the issuing authority. If the client confirms the trust, then, SSL communications can continue.

Frequently, small organizations decide not to use a third-party certificate or not to install their own PKI to issue their own certificates. They might make this decision because those solutions are too expensive, because their administrators lack the experience and knowledge to create their own certificate hierarchy, or for both reasons. The cost is minimal and the setup is simple when you use self-signed certificates. However, it’s much more difficult to establish an infrastructure for certificate life-cycle management, renewal, trust management, and revocation when you use self-signed certificates.

Summary:
So – there you have it. If you want to have Exchange working happily and trouble-free, my best advice is to buy a 3rd party SSL certificate and www.exchange-certificates.com is about the cheapest place around that you can buy an SSL certificate for Exchange from (even cheaper than GoDaddy and they are pretty cheap already!).

How To Configure Exchange 2010 To Delay Sending Of Emails With Large Attachments Until Approved By Moderator

Have you ever had a user on your network send out an email with a large attachment (or several large attachments) to a large number of recipients and brought your Exchange Server and Internet Connection to its knees as Exchange tries to send out all the messages with attachments as quickly as possible, flooding your outbound connection?

Well if that sounds familiar, then here is one way around the problem by use of Transport Rules.

With Exchange 2003 – you can make use of the option to delay large emails until after  hours, but this doesn’t exist in Exchange  2010, so you have to come up with an alternative plan to prevent this from happening.

The plan here is to setup a Transport Rule to send a message to the Administrator asking them to Approve or Reject the message containing the large attachment before Exchange starts to try and send the message(s) out, crippling your connection.

Open up Exchange System Manager and navigate to Organization Transport> Hub Transport> Transport Rules:

Once there, click on the New Transport Rule Wizard, give the new Rule a name and a Description to help you understand what the Rule does then click Next:

Select “From Users that are Inside or Outside The Organization”:

Then select “Sent to users that are inside or outside the organization, or partners”:

You then need to change the selection in Step 2 from Sent to users that are ‘Inside the organization’ to Outside the Organization:

Click OK.  The scroll down to the bottom of the list in Step 1 and select “When the size of any attachment is greater than or equal to limit”:

Once selected, click on the ‘0 B (0 bytes)’ in Step 2 and set the message size that you want to trigger the rule:

In the example above, I have set the size to 4Mb (4,096 Kb). Click OK after setting the size and then click on Next.

We now get to choose the Action to operate when the Criteria chosen is met and the action here is to forward the message to addresses for moderation:

Click on addresses in Step 2 and select your internal Recipient who is to receive the message to Accept / Reject:

Then click on the Add button to select the Internal Recipient:

Once you have selected the relevant recipient, click OK:

Then click on Next and add any Exceptions (if you wish) and click on Next:

We now see the completed rule:

Click on New to create the Rule.  Once completed, click on Finish to complete the Wizard:

You should now see the new Rule in the Transport Rules:

When the Rule is Triggered by an internal user sending a message with an attachment greater than 4Mb, the message will be forwarded to the chosen account for approval.  If approved, then the message will be sent out.  If rejected, the sender will receive a message advising that the message was not able to be sent and the Moderator can add a note as to why if they wish.

If you prefer doing things via the command line (Exchange Management Console), then you can use the following command to achieve the same result:

New-TransportRule -Name ‘Transport Rule Name‘ -Comments ‘Transport Rule Comment To Describe What It Does.‘ -Priority ‘0’ -Enabled $true -FromScope ‘InOrganization’ -SentToScope ‘NotInOrganization’ -AttachmentSizeOver ‘4 MB (4,194,304 bytes)’ -ModerateMessageByUser ’emailaddress@domain.co.uk’ -ModerateMessageByManager $false

Why are there so many bad IT Support companies out there who don’t have the first idea about IT?

Having taken on two new customers with SBS 2003 servers within the last week, the first server was in a very bad way with 58Gb of Exchange logs piled up since the last Exchange full backup in about August 2010 and the SBS 2003 backup hadn’t worked since the 23rd August 2011 (we 1st saw the server on the 15th September).

The SBS backup was configured but fell over the second it tried to start.  After a quick poke about, I edited the selections in the SBS backup job and then re-ran the backup.  This time it worked and started to backup.  It subsequently failed with a corrupt font file in the ClientApps\Outlook 2003 folder (so I replaced the file from the CD) and problems with the Exchange database, so I took the store offline, ran a repair (eseutil /p), defragmentation (eseutil /d) and integrity check (isinteg) and that solved those problems.  The backups are now running to the end and all 58Gb of Exchange logs have been purged from the disk – finally!

Updates had not been downloaded / installed on the server and WSUS was installed but had not synced to Microsoft since it was installed.  All very basic, simple maintenance tasks that should be performed by any competent IT company.

Backup Exec was installed – heaven knows why – as it wasn’t being used.  Probably made the IT support guy some money selling software that wasn’t necessary I suppose.

There were various errors showing up in the Event Logs, mainly Disk errors and IP AUTD failed to Initialize (simple registry fix for this).  A quick tweak to the registry and a restart of the DNS Server service and the IP AUTD error went away (see KB956189).  Waiting to run a disk check to clear the disk errors.

This customer apparently lost all their data when their server crashed recently and it took the IT guy 3 weeks to get their data back.  Presumably after this, they would have made sure the backups were working 100% – but this doesn’t seem to be the case.

Symantec Anti-Virus Management Console was installed – but there were no clients using Symantec Anti-Virus.  Symantec Mail Security for Microsoft Exchange was also installed, but the definitions expired in August 2008, so spam filtering wasn’t going to work, but then as they were using POP3 collection for their emails, what good was Symantec Mail Security going to do for them as it can’t scan POP3 collected mail – only SMTP delivered mail!

Turkey, Poland and Spain were very interested in the server and trying on a minute by minute basis to try and breach the Administrator account – so far unsuccessfully, but it probably won’t take them long if nothing is done to stop the attacks.  As soon as we get the go-ahead to start fixing the various issues – we will be bolting the server down and monitoring it for unwanted attention from foreign parts.

Having been shocked by one server in a week, we secured another customer and started to examine their server in detail, installing some monitoring software which picked up a lack of a completed backup by the SBS backup job, or the Backup Exec software that was also installed (but not configured).

On the second server – the SBS backup was configured to run and was happily running, but as soon as the backup had written about 4Gb of data to the external HDD used for the backups, the backup failed!  Guess what – the drive was formatted as FAT32 not NTFS so the backups were doomed from the start.  A quick re-format of the disk and the backup now completes successfully.

I have only scratched the surface of the 2nd server, so anticipate more problems to surface, but I just can’t believe how two different IT Support companies can provide such useless support and actually charge for their services.  It is beyond belief.

So – if you are happy with your current IT Support company then great.  Why not try asking them to recover a file from backup that you have accidentally deleted (moved to your Personal Computer) and see how long it takes them to recover it.

If you want an IT Support company that makes sure that the servers they look after are backing up properly, have Anti-Virus software installed and updated, doesn’t let spam through to the users because of excellent Anti-Spam software, then please give me a call or drop me an email.  I can happily review your existing servers and advise you if your backups are working properly or if something else is going wrong but you are blissfully unaware of it.

SBS 2003 Physical to SBS 2011 Virtual Migration completed

I have just completed a migration from SBS 2003 as a physical server to SBS 2011 as a Virtual Server running on Microsoft Hyper-V and the entire process went without a hitch.

As usual, the article that I followed was Demazter’s excellent migration article.

I did have some fun working out how to create and load up the SBS migration file needed on the SBS 2011 server to tell the installation that it is a migration, not a clean install. After some head scratching, I created a Virtual Floppy Disk file, loaded it onto an existing Virtual Server, copied the SBS Answer File to the Virtual Floppy Disk, dismounted it, re-configured the SBS 2011 Virtual Server to also load the Virtual Floppy Disk and that was ll that was needed.

Again, the entire process took 3 days – which so far every other migration I have performed has taken. The longest / slowest part is the migration of Exchange Mailboxes and data, but once that is done, the rest is much quicker.

So, if you are wondering if you can migrate to SBS 2011 in a Virtual Server environment, I can happily confirm that it can.