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

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 92,000 times in 2011. If it were an exhibit at the Louvre Museum, it would take about 4 days for that many people to see it.

Click here to see the complete report.

“An error occurred while attempting to move the Microsoft Sharepoint Foundation database”

Please check to see that the ports in use on the SBS 2003 server are 80 and 444.  I was just trying to move the location and it kept failing.

After a few searches with no useful information being found, I checked a couple of other SBS 2003 servers that I have access to and saw that the one I was trying to migrate was using port 81 and 444, so I changed the port to 80, stopped and started the website and then tried the move again and this time it completed.

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.

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!).

Looking into Active Directory users and Computers there is a handy Dial-In tab on User Accounts where you can set the IP Address up.  So having chosen a suitable IP Address that was part of the RRAS IP Range reserved in DHCP for Dial-In users I applied the settings and got the user to test the connection.  They somehow received a completely different IP Address to the one I had assigned!

So – this lead me to digging into the only other logical place I could think of that might be causing this to not work properly and that was the VPN Policies.

To get to the Policies, I opened up Routing and Remote Access (under Administrative Tools).

Once opened up, I clicked on the Remote Access Logging & Policies folder.  Having selected this folder, I then right-clicked the folder and selected Launch NPS.

This brought up the Network Policy Server window and from there I selected the Network Policies Folder.  In the Policies at the top of the list is the General Connection Authorization Policy, so I right-clicked this and chose Properties from the menu option.

On the General Connection Authorization Policy Properties Window – it became immediately apparent why the fixed IP Address I had assigned in Active Directory Users and Computers was not working.  Staring me in the face was a check box entitled “Ignore user account dial-in properties” and this was ticked by default, so I unticked the box and clicked the OK button.

I then asked my user to try the VPN again and this time the IP Address that I had assigned them was the IP Address that they received.

So – if you have been scratching your head over this for a while – it is as simple as assigning a fixed IP Address in Active Directory Users and Computers and unticking a check box.

Alan

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 2007 / 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

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.

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.

I may just wait in for the next 2 hours for a laugh to see if they do actually show up!

So – if you decide to opt for any of the Virgin Media Services that they offer – don’t be surprised if you keep having to take time off to stay in at home to wait for their engineers who simply won’t turn up when they are supposed to.

Things don’t seem to have moved on since the days of NTL and the service that they provided (which was also lousy), so you have been warned.

If on the other hand, you like staying in at home, having taken time off work to wait for one of their Engineers, then great – I hope you have plenty of tea / coffee on standby and enjoy the peace and quiet.

So – the appointment was scheduled for the 5th July 2011 between 8:00am and 1:00pm. So I sit at home and wait for them to turn up.

Come 1:05pm – I call them up and ask them when the engineer might appear and provide me with my broadband. After being put on hold for a while, they come back to me and advise me that the engineer was being a bit delayed but would be with me in about 40 minutes to an hour.

At 3:00pm and no sign of their engineer – I call them again and get put on hold yet again. Magically as I am on the phone, having held on for about 10 minutes, a Virgin Media van appears outside and I then end the call to their telephone support.

About 15 minutes after the 1st engineer arrives – two more appear and the three of them then work until about 4:20pm until my service is up and running. So far so good, but for an 8:00am to 1:00pm appointment – it is now 4:20pm and my whole day is wasted.

The 1st engineer advised me that he didn’t even have the job to get me installed that day and the others advised that an engineer was off sick and everyone had to re-arrange their days and rally round to get the work done – I feel so lucky to have such diligent engineers!!

Having then spent the evening trying to get the Virgin Media Super Hub to play with my own Router and establish the IPSEC VPN between the office and home, I give up, knowing that it wouldn’t work in the first place, but felt that it was rude not to give it a try.

The following day I borrow a Virgin Media Cable Modem from a customer who no longer is going to use the service and plug the modem in at home and try to get it working. Lo and behold – it doesn’t – so I call Virgin and ask then if they can make it work. Short answer is no because it is still registered to another customer and also because it won’t work on a 30mb service – I need to downgrade to a 20Mb service – so I downgrade and they promise to send me a new modem in a couple of days.

2 days later – as promised – the modem arrives and I plug it in – call them up – activate it and all works happily.

So that evening I again try to get my own Router to work on their connection and establish a VPN connection – which turns out to be impossible, although it should work.

On the Sunday I call them up and check to see if they are blocking any ports or restricting the service in any way and they advise me that they are not, but check the connection and advise me that it was a bit noisy and might be the cause of the inability to get the VPN working, so they schedule an Engineer to pay me a visit today between 12:00pm and 4:00pm (can you tell where this is heading yet?).

So, I get home today at 12:00pm and sit at home working remotely and doing what I can awaiting the engineer. I finally get a call from Virgin Media at about 3:30pm advising that their engineer isn’t able to make it today – some sickness again apparently and can I make another appointment. I advised them that I had already wasted 3½ hours of my day and that their offer of £10 compensation wasn’t going to cover the time I have wasted so they advised me to contact customer services – to which I replied – you can call them because I have better things to do with my time and whilst calling them, please cancel the contract as clearly this isn’t going to be a long and happy relationship if their engineers can only book a 4-hour slot and then fail to arrive 100% of the time within the agreed time-slot.

Be warned – if you decide to opt for a Virgin Media Service – make sure you have plenty of spare time on your hands as you will need it.

Sadly the alternative of Copper broadband involves BT at some point in the loop – who are equally as bad at turning up when they are meant to – so if you want broadband – make sure you have plenty of tea / coffee handy and something to occupy your time – you will need it.