URL in IM messages after forefront installation
-
Wednesday, May 13, 2009 9:37 PMHi all,
After instaling forefront, URLs in IM messages are being replaced by text. I mean on the other end instead of having a link for a user to click direclty, it appears as simple text.
I allow URLs in the Pool IM filtering, and the clients have the regkey : HKLM\Software\Policies\Microsoft\Communicator\EnableURL = 1
Before forefront hyperlinks were working fine.
Any help is much appreciated
Thank you
All Replies
-
Thursday, May 14, 2009 2:58 AM
Paulo,
Are you seeing this behavior with Communicator 2007 or 2007 R2 clients?
ShreyS [MSFT]
Forefront Server Security -
Thursday, May 14, 2009 9:45 AMHi Shrey,
with communicator 2007.
Well to be more accurate, I only got feedback from one R2 client user, and in this case, the first time I did the test the URL was replaced by something similar to a HTML code....
I never tested again with an R2 client, because it's not the one officially deployed.
However I have to correct my first statement:
- Before Forefront installation, I had the pool filtering configured to replace URL's with text. But, for the Clients I had the regkey deployed, which means that even with the pool setting, all users were able to send URL's.
- After Forefront Installation, without changing any setting, URLs stopped being sent.
- Now I have changed pool filtering setting to allow URLs, and it started working again!
So, my assumption was that even with the pool setting not allowing URL, the client regkey overrides that setting. And after forefront installation, it is blocked?!
Does this make sense?
Thanks -
Friday, May 15, 2009 4:50 PM Paulo,
In this case, Forefront is treating the IM message as being invalid. You'll notice that the sending client (with the EnableURL=1 key set), receives a 400 response when attempting to send a URL. This indicates that Forefront failed to validate the message. The symptoms you are experiencing is a known issue with the way that Forefront for OCS parses RTF content; specifically the RTF tags used to represent clickable hyperlinks from the sending client. This will be addressed in the next Rollup for FSOCS.
In the meantime, you should be able to alleviate the symptoms by setting the following regkey:
HKLM\Software\Microsoft\Forefront Server Security\Office Communications Server\AllowInvalidContent = 1
If you choose to do this, keep in mind that this will disable some basic content validation that Forefront for OCS attempts to perform (such as checking for well-formed RTF). These checks may or may not be necessary in your environment depending on whether you allow federation and/or have custom IM clients running. While these checks are bypassed, all content will still be passed to the Forefront scanning processes for keyword filtering and/or virus scanning depending on your configuration.
HTH,
ShreyS [MSFT]
Forefront Server Security- Proposed As Answer by Mark Domansky Thursday, June 11, 2009 12:56 PM
-
Friday, May 15, 2009 9:50 PMShrey,
actually, I faced that exact same problem (error 400), even before changing the pool IM filtering to allow URLs.
I read about that regkey in documentation, and decided to try.
After creating the key, I stopped receiving the 400 error, but URL is delivered in text. Where before FSOCS installation was deliveres as a link, due to the fact of the client have the EnableURL regkey deployed.
So, here 4 different scenarios:
First scenario (Before FSOCS) : Pool IM filtering configured to replace URLs links by text.
- Client with EnableURL regkey - Result : URL received as a link
- Client without EnableURL regkey - Result : URL received as text
Second Scenario (after FSOCS Installation) : Pool IM filtering configured to replace URLs links by text.
- Any client - Result : error 400
Third Scenario ( AllowInvalidContent Regkey deployed) : Pool IM filtering configured to replace URLs links by text.
- Result: Any Client Received URL as text. Even the ones with the EnableURL regkey
Fourth Scenario ( AllowInvalidContent Regkey) : Pool IM filtering changed to ALLOW URLs links.
- Result: All URLs received as links.
So, my question is, why does in the third scenario all was replaced by text? It should have the same behaviour as first scenario, because the client regkey would override the pool setting, right?
Right now, I can't control the URL links with the client regkey, I had to allow it at pool level.
Thanks!
Paulo Trilho -
Monday, May 18, 2009 8:35 PMPaulo,
Based on my understanding of the EnableURL policy, both the sender and receiver of the hyperlink need to have it enabled for clickable links to be sent. That said, have you verified scenario #1 from/to clients with different settings for the EnableURL policy? Note that for the key to take effect, Communicator needs to be restarted. I ask because FSOCS does not modify the contents of the SIP payload unless some filter detection has occurred and should not affect clickability of URLs.
If the sending client does not have the EnableURL=1 set, then it does not generate the clickable hyperlink in the SIP message payload. On the receiving side, if the receiver does not have EnableURL=1 set, the it does not render the clickable hyperlink in the RTF control. In the case that the sender does not generate a clickable hyperlink, a receiving client with EnableURL=1 set would not receive a clickable hyperlink to render in the RTF control.
HTH,
ShreyS [MSFT]
Forefront Server Security -
Tuesday, May 19, 2009 8:03 PMHi ShreyS,
in fact yes, that's also my understandig.
And regarding the first scenario, yes, only two users with the EnableURL regKey would send URL as link. Sorry if i was not clear about this.
But that is not my doubt here.
The question is regarding the scenario three:
Even beetween two clients with the EnableURL link, right after creating the "AllowInvalidContent Regkey" on the front end servers to overcome the error 400, any URL would be replaced by text.
I had to change the setting at the OCS pool level to have URLs as links again!
See my point? Is this expected?
Thanks!
Regards. -
Thursday, May 21, 2009 1:43 PM
Paulo,
What you are describing is not expected behavior as far as FSOCS is concerned. I am not able to reproduce the issue you are describing. A few things for you to consider:
- When you are sending a link, does the sending client's IM window render the sent message as a hyperlink? If not, this indicates that the sending client is not generating the clickable link; you should validate that the EnableURL group policy has taken effect.
- If the IM content does not trigger a configured FSOCS filter, FSOCS does not modify the message content. The standard behavior for FSOCS to replace contents of an IM message would typically occur when a malware detection occurs. Each time content replacement takes place, the FSOCS performance counter "IMConversationsBlocked" is incremented. When sending a clickable link, you can check to see if this performance counter is incremented to determine whether FSOCS is modifying the content.
If you think that FSOCS is involved with this behavior, I'd recommend opening a case with Microsoft CSS so that we can help you troubleshoot this issue further.
Regards,
ShreyS [MSFT]
Forefront Server Security- Proposed As Answer by ShreyS [MSFT] Thursday, May 21, 2009 1:44 PM
- Marked As Answer by Jim MoliniMicrosoft Employee, Owner Friday, May 22, 2009 12:55 PM
.png)
