Connected Blog

As a Microsoft unified comms specialist partner, we run Microsoft Office Communications Server 2007. It works a treat in an EBS environment, in fact, EBS provides the ideal bas As part of our setup, we have an OCS edge server which allows users outside the company to connect to our OCS infrastructure and make use of it’s services, e.g. IM, presence, voice etc.

We have a number of people (partners, consultants etc) who would benefit from using OCS, but will never actually log on to our main network and access EBS resources. As such, we created some new user accounts in active directory and set them up for OCS. After enabling them for remote access, some of them were able to log on to OCS externally. After a short period of time, they couldn’t log on, and we could not figure out why. Every aspect of the users and OCS configuration seemed to be ok.

Eventually, we figured out what it was – EBS licensing. Each user had to be assigned a user CAL within the EBS management console. A quick query with the EBS team confirmed that this is expected behaviour. As the user authenticates to AD (even though they never access any other resources), they require a CAL. This is true whether running standard Windows or EBS, but the difference is that EBS ENFORCES the licence requirement whereas Windows does not.

So, external OCS users who authenticate require an EBS (or Windows if not using EBS) user CAL, and OCS standard user CAL and an OCS enterprise CAL to enable the full suite of OCS functionality. If they are a voice user and require exchange UM, they would also require an Exchange Enterprise CAL.

This one had me stumped for a while - remote web workplace on our EBS system had been working fine, but suddenly stopped working. I could login to RWW no problem, pick a machine from the list and try and connect, but would then get a dialog with "An internal error has occured (error 50331656)."

Searching online found virtually nothing related to this message other than someone having a RWW issue on SBS.

After some investigation ourselves then involving the EBS TAP support team, we tracked it down to the lack of a certificate on the Terminal Services Gateway. This Server 2008 role is installed on the Messaging server. After assigning the correct certificate, RWW works perfectly.

I later realised what caused the problem - we had a certificate on our EBS messaging server which didn't include autodiscover.domain.com and autodiscover.domain.local so we created and assigned a new one, while deleting the old one.

We didn't realise that this certificate was also assigned to the TS Gateway and deleting the certificate left it without one assigned.

I'll talk about autodiscover and certificates in a forthcoming post.

Service manager has looked like a very interesting product for change and configuration management as well as helpdesk operations. There was a Beta 1 released over a year ago, but the product team decided to scrap the original product and go back to the drawing board.

The bad news was the release was pushed back to 2010! The good news is Beta 1 of the new version has just been made available:

https://connect.microsoft.com/SelfNomination.aspx?ProgramID=2733&pageType=1&SiteID=446

We needed a new certificate on our Exchange 2007 CAS server including the autodiscover prefixes in the SAN, so I wanted to submit a new request to our internal CA.

The process was as follows:

1) Use the Digicert tool https://www.digicert.com/easy-csr/exchange2007.htm to quickly get the command line required including the SANs

2) Enter the command line (New-ExchangeCertificate) on to the exchange server (in our case our EBS messaging server)

3) Submit the created request file to our internal CA (EBS Management Server). This is where the problem arose - when trying to process the request from the certification authority MMC, I got an error 0x80094801 - the request contains no certificate template information.

The solution is to use certreq.exe with the following paramaters to specify the template to be used:

certreq -submit -attrib "CertificateTemplate:WebServer" request.txt

4) Process the pending request on the messaging server using IIS

5) Use Get-ExchangeCertificate to list the available certificates

6) Copy the thumbprint from the output of 5) and use Enable-ExchangeCertificate to enable the new cert for the web services.

Enable-ExchangeCertificate -Thumbprint THUMBPRINT -Services IIS

And we should be good to go!

I've been working on an OCS enterprise voice deployment with Exchange Unified messaging and as part of the process was setting up an auto attendant.

I got the routing all working and could call into the AA, but got a voice message "Please call back later. Goodbye" and was disconnected. I eventually made the AA not speech enabled and then when calling in, got the expected "welcome to the Microsoft Exchange auto attendant".

Checking the log files on the UM server indicated a problem with one of the grammar files for Automatic Speech Recognition.

I'll fix this later, but at least I now know where the problem lies and have some error messages to go on.

Today, I needed to download a password protected zip file (as it happens, beta OCS compatible firmware for an IP phone), but when downloading, was presented with the following:

As TMG is unable to decrypt the file and inspect it's contents, by default it's blocked.

This is controlled by the malware inspection policy in TMG.

Under the block encrypted files setting.

I needed this file, but obviously didn't want to open a security hole, so I added the specific site to "Sites Excluded from malware inspection" on the exceptions tab.

When I now attempt to download the file from the web site TMG allows it through ok.

Nick King, technical product manager for EBS has just presented the first EBS focused session at this year’s TechEd EMEA. I was pleased to see the room about 80% full and obviously a fair amount of interest in EBS.

Nick presented a deep dive on EBS 2008 covering product details and the deployment process in some detail. Virtualization was discussed numerous times, including a look at the different supported scenarios using Hyper-V.

Gary Purchase then went on to give a quick demo showing how easy it is to develop add-ins for EBS.

Nick announced that a trial version of EBS will be available from 12th November!

I’m now into my second day of TechEd EMEA 2008, with a focus around EBS and Unified Comms. I’ll post reviews and notes on some of the sessions as the week goes on.

I’m here with the EBS team at the Windows Essential Server Solution stand and will be on hand most of Thursday / Friday to answer EBS related questions.

I’m also taking part in a chalk talk session on EBS on Thursday afternoon alongside Oliver Sommer and Mikael Nystrom, two MVPs also heavily involved in the EBS TAP program.  We will be talking about each of our EBS production deployments, our experience and lessons learned.

We’ve now been running the RTM version of EBS for a couple of weeks and everything is looking good.

The actual migration from Release Candidate 0 to RTM was a fairly painless process, and for the management and messaging servers simply involved installing various Windows Server 2008 updates and updating the EBS components.

The security server migration actually involved replacing the server using the EBS replacement mode install. I recorded any changes we had made to the firewall rules etc in TMG and then simply rebooted the server from the RTM security DVD. Replacement mode worked flawlessly, picking up the relevant settings from the configuration partition.

After completing the security replacement mode install, I simply recreated our customer firewall rules and we were good to go!

Note: Now that we are RTM we would be able to export and import the rules from TMG rather than re-creating them, it’s just that there were significant changes from the beta to RTM.

So far our first couple of weeks living with EBS RTM have shown no issues at all.

It feels pretty good to have been the first in the world to start a production deployment of EBS and the first in the UK to be RTM!

Look out for lots more EBS posts in the coming weeks, including articles on DPM, and Office communications Server integration.

Last weekend, we completed our third EBS production deployment as part of the EBS tap program, and I have to say, I was astounded, not only by the ease of install, but also by the speed!

This table shows how long it has taken us to complete the deployment of the 3 core EBS servers (not including the guided configuration).

Now all these installs have been into different environments, but the key point is how comprehensive and robust the EBS setup process is as we approach the release version. Not only is the setup itself very robust, but the preparation and planning tools allow you (actually, force you) to identify pre-existing issues with your environment and fix them before being able to install EBS.

I'd like to say a big thank you and congratulations to the EBS setup team, as this shows just how much effort has gone into this and what a great result you have achieved!