PointBridge Blogs - Matt McGillen

12/11 is Doomsday for RMS and Office 2003

By: Matthew McGillen Posted: December 14, 2009 at 10:08 AM

A client just had a nasty little issue with Rights Management Server today: it stopped working. Yeah, that's a pretty bad issue. As it turns out, anyone with RMS and Office 2003 will have this same experience. From the KB:

Starting on December 11, 2009, customers using Office 2003 will not be able to open Office 2003 documents protected with the Active Directory Rights Management Service (AD RMS) or Rights Management Services (RMS). Customers will also not be able to save Office 2003 documents protected with AD RMS/RMS. Cause: The issue has been identified as an Office 2003 certificate expiration issue.

That is definitely not awesome. Luckily there is a hotfix link in the KB article that resolves the issue. If you don't want to install the hotfix, the "workaround" in the KB article is rather humorous: "Open the document using Office 2007." Oh!!

Thanks to Patty for alerting me to the issue!

OCS 2007 R2 CWA - PIN Length Part II

By: Matthew McGillen Posted: October 7, 2009 at 3:02 PM

As a follow up to my previous post on the CWA PIN Length issue - I have something that solves the issue - for now. Of course it's not officially supported by Microsoft etc. etc. (MS says it will be fixed in Wave 14… grr!!!) but I think this a pretty clean way to change the display text.

It occurred to me that instead of messing with the ".resource" files (which were in some sort of binary format) that contained the offending string, we could just modify the bit of HTML that was calling the variable in the first place. Jeff Schertz and I spent a little while today hacking through the ".js" files on the CWA server and located the piece that actually referenced the resource file variable. We swapped the variable itself for the whole string of text that we actually wanted. And it fixed the prob. See below for instructions

Edit the DialinForm.js file on the CWA server (you should make a backup just in case):

C:\Program Files\Microsoft Office Communications Server 2007 R2\Communicator Web Access\Server\cwa\Client\Dialin\DialinForm.js

Locate the following line containing the string 'txtNewPINDesc':

document.getElementById("txtNewPINDesc").innerHTML = txtNewPINDesc_res;

Change the variable with a static description using the desired PIN length:

document.getElementById("txtNewPINDesc").innerHTML = "Your PIN must be at least 27 digits and cannot include letters, spaces, sequential numbers, roman numerals, kanji, klingon, or lewd content. Customize this description as you see fit.";

Reload the Dial-in Conferencing page (you'll need to do an F5 to refresh - it keeps a cached version of the old text otherwise)
Bingo:

So you can now correctly apply the PIN policy number to your CWA page. I'm sure that if you update/patch CWA, this will all get overwritten, but it's a really easy fix to re-implement.

But really, I wish this would just get fixed properly sometime before Wave 14 - it's quite confusing to end users. And plus: who has a 5-digit PIN??? It would be seem to me like something that could be included in the next hotfix / rollup. Who knows - maybe we'll get lucky.

OCS 2007 R2 - CWA PIN Length Bug

By: Matthew McGillen Posted: October 5, 2009 at 11:50 AM

(10/07/2009 - I've updated this issue in a newer post)

I noticed something odd a while back when we deployed OCS 2007 R2 for audio conferencing: that the webpage where users go to reset their PINs always says that PIN length must be a minimum of 5 digits.

Even if you have set your PIN policy in OCS to be less than 5 (in my case, 4) that text in the message never updates.

I'm no web development genius, but I figured changing a "5" to a "4" in HTML was well within my capabilities.

So I went to edit the page (which lives on the CWA server): %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Communicator Web Access\Server\cwa\Conference.aspx. And I found what I thought was the right place:

But you'll notice that the text doesn't really match up… this HTML is for "Create New PIN" not "Set Your PIN". But it was the only reference to PIN digits in the whole page. I soon realized that, for whatever reason, the text must be in a different file - somewhere else on the CWA server.

I looked through all the ASP files and HTML but nothing had the right text. But it looked like it was somehow being stored as a variable of some sort.

And after some digging, I found "C:\Program Files\Microsoft Office Communications Server 2007 R2\Communicator Web Access\Server\cwa\Client\App_LocalResources\Dialin_Resource.aspx.en.resources".

Hmmm… it looked like a resources file stuffed with all sorts of messages and places for variables. Further - it appeared to be "compiled" (odd characters / spacing etc) in some way where just changing the text didn't seem like it was going to be a good idea. This was definitely the place - but I was too chicken to touch anything.

After checking around with a few people here at PointBridge and within MS - we decided that opening a case with PSS was the best route. One of the guys from MS confirmed that playing with the resources files caused CWA troubles.

I expect that they will have a bug ID created & this should be fixed in a hotfix.

But my advice is - don't try to fix it yourself. CWA will do bad things if you monkey with the resource files. I'll post more info once it's resolved.

OCS - Integration with Google, IBM, Jabber and more

By: Matthew McGillen Posted: October 1, 2009 at 2:21 PM

Good news: OCS can now federate with lots of other vendors, including Google and IBM Sametime.

http://www.microsoft.com/presspass/features/2009/oct09/10-01ucinterop.mspx

This is great news for the UC world in general.

More info to follow on how it actually works in production…

OCS 2007 R2 - QoS on the MOC Client (especially with 64-bit clients!)

By: Matthew McGillen Posted: August 27, 2009 at 2:34 PM

12
Comments

I've been fiddling with QoS and OCS for the past few days and have some insights to share.

First important point is that OCS will support QoS via DSCP marking. But it is not enabled by default on any OCS servers or clients, but can be enabled. Microsoft has some pretty useful info on how to make that work. Straight from TechNet on the MS philosophy of QoS:

Although Office Communicator Server 2007 has been designed to work without any QoS framework, it is possible to configure the media stack to mark the IP traffic conveying the real time audio and video IP traffic according to well established classes of services.

The marking may be enabled or disabled by means of registry keys. If enabled, the marking of the IP packets is done by the QoS Packet Scheduler service. The resulting marked packets can subsequently be recognized by network entities (end systems and routers) to manage the media traffic according to the QoS priorities.

And the correct registry entry (a DWORD) is as follows:

HKEY_LOCAL_MACHINE\Software\Microsoft\RTC\Transport\QoSEnabled =1

That's actually the "main" one to change. If you do that, your voice traffic gets marked with a DSCP value of 40 and video gets marked as 28.

QoS with Cisco Switches and Routers

In my experience, most QoS policies (especially Cisco) prefer to treat voice as Expedited Forwarding traffic - the highest level of DSCP QoS - a value of 46 . And for video, it normally should be marked as "assured forwarding" - a value of 31. )

Cisco networks that are already set up to prioritize IP telephony traffic will be looking for these markings, not the MS / OCS defaults. It's possible to use other values (like the MS defaults) but I'm pretty sure that EF / AF is the way to go in most cases.

So to make that happen - you can use Group Policy - or just manually set the registry entries like this:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\DiffservByteMappingConforming\ServiceTypeControlledLoad = 31 (Decimal)

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\DiffservByteMappingConforming\ServiceTypeGuaranteed = 46 (Decimal)

It's probably a good idea to set the following as well:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\DiffservByteMappingNonConforming\ServiceTypeControlledLoad = 31 (Decimal)

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\DiffservByteMappingNonConforming\ServiceTypeGuaranteed = 46 (Decimal

When you do this, you can run a network capture in wireshark and see that the voice packets are being marked properly:

As well as the video packets:

Case closed. Welllll… not totally: my 64-bit clients, for some reason, were not actually marking the packets properly.

64-bits and QoS with MOC

I've been running Vista for a long time (I appear to be one of tens of people who actually really love Vista & haven't moved to W7 yet) and I've never been able to make the QoS policies work on it. All packets were showing up with 0x00 in the DSCP field. A co-worker and I finally had reached the end of our patience and decided to get to the bottom of the mystery. We both had the same problems, he on W7, me on Vista. Nothing worked… until it dawned on me: we were both running 64-bit OS. That seemed like a likely cause, but I wasn't sure exactly why.

My co-worker, Aaron, suggested that we try making the above registry entries in the "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node". Brilliant! MOC is a 32-bit app, even on a 64-bit machine. So I created all the correct entries:

HKEY_LOCAL_MACHINE\Software\WoW6432Node\Microsoft\RTC\Transport\QoSEnabled =1

HKEY_LOCAL_MACHINE\SOFTWARE\WoW6432Node\Policies\Microsoft\Windows\Psched\DiffservByteMappingConforming\ServiceTypeControlledLoad = 31 (Decimal)

HKEY_LOCAL_MACHINE\SOFTWARE\ WoW6432Node\Policies\Microsoft\Windows\Psched\DiffservByteMappingConforming\ServiceTypeGuaranteed = 46 (Decimal)

And then, just like that, Vista 64-bit was marking packets. I tested audio and video; to my delight QoS was working properly.

QoS on OCS Servers

Getting QoS deployed and configured on the OCS servers is a different matter - although it's similar in concept to making it work on OCS clients. I'll save that for a later date.

Quick Launch
View All Site Content

About Matt McGillen

Tag Cloud

External Links

‭(Hidden)‬ Admin Links

Quick Launch View All Site Content

About Matt McGillen

Tag Cloud

External Links

‭(Hidden)‬ Admin Links

Quick Launch
View All Site Content