Vinny blogged the other day about Google Apps for your Domain and the Sametime Gateway, which is also covered in Technote 1295505. Well it happened to me :(. Someone in the organization (we are not quite sure who) registered the domain name for Google Apps, resulting in the loss of Google Talk awareness on our gateway. We managed to take over administrative control of the domain, and delete it from Google Apps, we are now waiting the “up to five days” for the domain to fully be deleted and we hope to have Google Talk working again. So what I am wondering about is how Google allows anyone to register a domain in Google Apps and begin rerouting IM traffic without proving ownership of the domain? The other question is how do we prevent this from happening again, we were hoping to fix it by just disabling the chat service in Google Apps, and then maintaining administrative control, but apparently we need to delete the whole thing, so how do we prevent another person from registering us on Google apps? Thats one for Andy and Vinny to figure out with Google and get back to us on.
Category Archives: sametime
AOL to support XMPP
A question that came up a number of times at Lotusphere was when MSN would be supported by the Sametime Gateway. It seems clear from the responses that while there are technical issues, the business issues of Microsoft agreeing to the federation is the real blocker. While this is going on it looks like AOL is moving to support XMPP. According to a comment left by an AOL Architect
Thanks for blogging about our commitment to openness. We’ve been working really hard over the past few years in making all of our services more open and standards based, working with the SIP as well as the Jabber/XMPP communities. Our XMPP gateway at xmpp.oscar.aol.com, which we’ve been working on for a while now, is just one approach we’re tinkering with. As you pointed out, though, this particular server at xmpp.oscar.aol.com is a test server, so I wouldn’t count on it being reliable or even continuously available until we put some more work into it to bring it up to our standards.
So while MSN continues to be proprietary, and for now not willing to federate with IBM, AOL is moving to be more open and compatible. If AOL moved to a stable XMPP implementation it could eliminate the need for provisioning for gateway connectivity to AOL.
How Sametime Gateway Requests Route through Sametime Servers
Disclaimer: This information was received and posted with permission by resources in the Sametime Level 2 support team. It is provided as is for reference only and subject to change. A common question when working with the Sametime Gateway is how requests route between the gateway, and the Sametime community. When setting up the gateway the only connection you define is from the gateway to one Sametime sever in the community. From there the gateway will discover the other servers in the community. Inbound and outbound requests are handled differently “Inbound requests (external user adds internal, external initiates a chat) are forwarded Round Robin by the Gateway server to the next server in the round robin list. This can be any server that is in the Sametime Community. The Sametime server that gets the inbound requests does the lookup on the user being subscribed too. If the community server that got the request isn’t the server that the internal user is connected to, then the request will be routed (internally, among the ST servers themselves) to the correct Sametime server. This would be for both request to add user to contact lists and the chats themselves. In a non-clustered environment where a Sametime Home Server is specified, the Gateway server will still round robin these inbound requests to the next server, but the Sametime server will now use the SametimeServer value to route the communication to the user’s home server. This would be different than routing it to the server he is logged into. Outbound is different. (Internal user adds external user) The server the user is physically connected to does the lookup on outbound ” The key here is that all servers in your local Sametime community regardless of the service they provide, must be accessible to the Sametime gateway on port 1516, in addition in the LDAP Server of your stconfig.nsf you need to make sure the search filters can resolve the e-mail address on all the servers as well. 
Sametime 8 Gateway and the LDAP Configuration wizard
There are a number of things I wanted to blog about this week, but it has been a busy week upgrading our Sametime 7.5.1 Gateway to 8.0, and building a Lotus Connections pilot environment. I will try to get to some of the other topics, but for now I want to cover briefly one of the enhancements in the 8.0 Gateway which is the LDAP Configuration Wizard. In the Sametime 7.5.1 Gateway you had to follow this 35 step process to configure the Gateway to use your LDAP. Sametime 8.0 you simply complete the wizard during install and it is done for you. 
Sametime 8 Mobile on Blackberry
I have been running Sametime 8 on my Blackberry for a few weeks, now that it has shipped I can share some screenshots. The look and feel is all upgraded to the new Sametime 8 look, so the green icon is gone, and the login screen is upgraded. 
Sametime 8 is out
It wasn’t at 12:01 AM this time, but Sametime 8 is out. Downloading the Gateway now.
Sametime and NAT Support explained in one simple diagram
The developerWorks Notes from Lotus Support blog, has just posted a new diagram detailing where NAT will work in a Sametime Environment, and where it won’t. I have spoken to many fellow customers working on Sametime Gateway implementations and this is definitely one of the most popular questions asked.
Sametime 8 Release notes are out
A technote popped up this morning with the Sametime 8 Release Notes. The pdf which can be downloaded here seems to contain information relating to the Beta releases. Hopefully this means we will see a Sametime 8 release this week. Update: Ed has confirmed the 11/29 ship date for Sametime 8
Photo refresh in Sametime 7.5.1 business cards
We recently went live with out Sametime 7.5.1 servers so people now see their photos in the business card section, prompting many people to want a new picture, so the question arose after changing ones photo how long does it take for users to see the new photo. If a user has never had your photo before then it is almost immediate, however once I have seen your photo it is cached locally, and the client by default will not attempt download a new photo for 7 days. The default cache period can be changed by editing the plugin_customization.ini (in the directory where Sametime is installed) and add ‘com.ibm.collaboration.realtime.imhub/lookupExpirationDays=x’ where x= the number of days to cache the photo. You can set it to 0 to lookup the photo every time, but that could have an impact on performance. Technote 1264766 details all of the possible preferences that can be set via the plugin_customizations.ini, and technote 1261055 details how to package them up and send them to users via the update site. Finally if you are not using photos at all technote 1260018 details how to prevent users from seeing the empty gray box where the photo would be displayed.