Update WSUS to show Windows 8 Computers as Windows 8 not Windows XP

If you have a server running Windows Server Update Services 3.0 SP2 (SBS 2003 / SBS 2008 / SBS 2011 etc) and you also have some Windows 8 clients that you have joined to the domain, they will probably show up in WSUS as Windows XP Clients not Windows 8!

To resolve this, please install the following patch from Microsoft:

http://support.microsoft.com/kb/2734608/en-us

Once installed, you should see the Windows 8 clients reported as Windows 8.

Yet more Bad IT Support Companies!

Following on from my earlier Blog Post about bad IT Support Companies (here) I visited a potential new customer today to look over their IT.  The background information I got from the company was that they had used their existing IT Support Company (a one-man band) for the past 5 years or so and whilst mostly happy with their service, there were some outstanding issues that were being neglected and this was causing some concern to the company.

They had recently installed a ‘server’ and their IT wasn’t running as smoothly as they had anticipated, so wanted to get a 2nd opinion about their setup and my company (IT Eye Ltd) was recommended by a mutual company.

Once I arrived, I had a quick look over their IT and came across 4 PCs and a Netbook.  Asking where the server was, I was directed towards an HP xw6600 Workstation with a label on it suggesting it had come out of a company in New York City (NYC-XXXXXXXXX)!  I then used Remote Desktop to connect to the server and discovered that it was running SBS 2008.  This prompted the question about when the server was purchased and I was told May of 2012.  I then asked how much they had paid for the server and they advised me £2,500.

Okay – so they had a recently installed SBS 2008 server of which Exchange 2007 was now no longer supported by Microsoft because the Mainstream Support had now expired!  That begged the question why SBS 2011 wasn’t installed and to that there wasn’t an answer.  I then looked for a license sticker and couldn’t find one, so that also begged the question if they were actually legal.  This conversation continued to the other workstations and no conclusive evidence was available to suggest that they were even remotely compliant.

Looking at one of the XP workstations I saw that it was running XP pro, so checked to see if it was part of the Domain and saw that it was still configured as a Workgroup.

Data was being shared from the server, so at least the server was being used for something other than a drain on their electricity bill, but data was still being held on the Netbook and the data wasn’t being copied to the server or backed up, so was at risk of being lost.  No evidence of server backup was visible either.

I then asked about emails and found out that they were being hosted externally (1and1) and were being collected via Outlook configured as an SMTP/POP3 account and to allow for shared calendars to be accessed, they had turned to Google Mail.

I then pointed out that their server had Exchange built-in and that they need not pay for mail to be hosted externally or use Google Mail for shared Calendars as they could do everything on their own server.

At this point – I think they had decided that they were not being well looked after by their existing IT Support Company and I left them pondering my findings.  We will wait to hear from them and see how they want to proceed.

Alan

SBS 2008 / 2011 Disk Space Eaten Up By SharePoint SQL Log Files – How To Reduce The Log File Size

Having been asked to look at an SBS 2008 server with a 74gb C: drive partition that was regularly running out of space (4.5Gb left when I checked this morning) and after freeing up whatever I could using the usual methods of disabling WSUS log files and clearing out old logs etc using the following article:

http://blogs.technet.com/b/sbs/archive/2010/03/02/recovering-disk-space-on-the-c-drive-in-small-business-server-2008.aspx

I decided to see if there was something more that I could do that was slightly more permanent.

I downloaded Windirstat from Sourceforge and installed it onto the server and let it scan the C: drive of the server.

When it had finished scanning, I noticed that by far and above the largest amount of data on the C: drive was being eaten up by the Sharepoint Config SQL Database Log File – amounting to about 24Gb of disk space!  What the heck?

A quick poke around the internet landed me on the following link:

http://luka.manojlovic.net/2008/06/15/reduce-sharepoint-services-30-logldf-files/

Which allowed me to reduce the overall log files size to about 500Mb and the C: drive of the server now has a more satisfactory 27.9Gb of free space and is no longer sending me errors about the disk space running low, which is always welcome.

One slight issue I had when trying to look at the properties of the Database to change the Recovery Model to Simple was a lack of permissions and an error, but a quick search again landed me on this page:

http://www.sqldbadiaries.com/2010/08/24/property-owner-is-not-available-for-database/

Now I am by no means an SQL Guru, but I managed to work out how to change the Database Owner from NULL to SA by right-clicking on the Sharepoint_Config…………….. Database and choosing New Query.  Then just type sp_changedbowner ‘sa’ and press F5 to execute the command and bingo, the database owner has been changed and you can now look at the Database properties without seeing an error and thus you can complete the shrinking of the Log Files.

Hope that this frees up tons of space for you too.

Alan

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 Assign a Static IP Address to a VPN Client in SBS 2008 and SBS 2011

Have you ever wanted to assign a Static IP Address to a Dial-In user on your SBS 2008 or SBS 2011 server and wondered how to do it?  Well, until recently this was not something that I had ever had to spend any time thinking about, so had not even tried it myself.

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