Tuesday, December 27, 2005

Live Meeting Integration with Communicator

If your company uses Microsoft Office Live Meeting you can establish a session via Office Communicator 2005 in one-click. For the other contacts in the chat, they have to make just 2 clicks.

Assuming you have Communicator installed, the first step is to install the latest Live Meeting 2005 Add-in pack.

You are prompted to configure your preferences next. It is important to get the correct URL for you company. Also note that the username and password is for the Microsoft Live Meeting servers. For those of you using Live Meeting Portal, you have to ask your administrator for the password if they do not make it available. I will cover Live Meeting Portal in a future release.

The final step is to configure the Live Meeting settings to create a new session with an attendee limit higher than 2. This allows you to start a Live Meeting session when you have a IM discussion with more than one person. By default, the session size is 2.

In the Start Menu select Microsoft Office Live Meeting Meet Now Options. Change the Session size to something larger than 2 (e.g. 5). Select OK.

If you want to start a Live Meeting with a contact, right-click on their contact and select More Start Microsoft Office Live Meeting. If you already have a conversation window open with one or more contacts, just select the Live Meeting button at the top.

Friday, December 16, 2005

LCS IM for Blackberry

Handango is offering an entry level IM client for the Blackberry that can connect to LCS and MSN. $45. It looks pretty weak compared to the Mobile Communicator pictures I've seen.

Wednesday, December 14, 2005

Issue Converting .Net Messenger Accounts for LCS

When implementing LCS 2005 with public IM connectivity, all users who have IM accounts using your corporate domain (e.g. will @corpdomain.com) have to convert their accounts to a Microsoft domain (hotmail.com, messengeruser.com) in order to maintain their contact list when using MSN Messenger. We have ran into issues with this conversion process, escalating to MS, and have a solution, albeit not a good one.

This article provides a straightforward description of why you have to convert and includes a link to quickly convert. You get to choose a new IM account name and MS converts the account in about an hour the article states. Essentially, once the conversion takes place and your contacts login again, their contact for you is converted to the new account. There is no disruption. We have found that sometimes when the person converts and then logs in with the new user account, even a day later, all of their contacts appear offline. Reboots and attempting to login with the corpdomain.com account do not work.

MSN support recommends:
  1. Log in to MSN messenger with new account name.
  2. Export your contacts to a file (Option in Menus)
  3. Delete all your contacts manually
  4. Import the contacts file.
We have found this works fine but is not a satisfactory solution if you are converting dozens of accounts and this happens frequently, especially for less technical savvy users. A MS MVP noted that the conversion may take a couple days if ever. It may be quicker just to walk the person through the above steps.

Adding EASI Accounts to Communicator

When implementing LCS 2005 with the public IM connectivity feature, there are a couple extra steps to take to be able to add MSN IM accounts to your Communicator client. First I want to touch on what happens when you implement LCS and MSN IM accounts associated with your corporate domain.

Converting Corpdomain.com Accounts

Some users in your company will inevitably create MSN IM accounts using their work email address (e.g. will@corpdomain.com). Once you implement PIC (public IM connectivity) with LCS for corpdomain.com, users can no longer login to MSN Messgner with their IM account. This is not a big deal if the LCS implementation occurs over a weekend and there is no downtime to the users. The users simply re-add their contacts to the Communicator client and start using this as their IM client. However, the users may want to maintain a separate IM account with all their contacts with no disruption. The users need to convert their corpdomain.com IM accounts to a MS account. The following article provides good instructions on how to convert the IM account to a messengeruser.com or msn.com account. In theory, you wait an hour after conversion and once all your contacts login again, their contacts lists reflect your new account. I have seen sporadic issues with this process which I'll cover in a different entry.

EASI Accounts

EASI accounts are IM/Passport accounts using non-Microsoft owned domains. Until recently, you could not add IM accounts to Communicator that were EASI accounts. There is a good article on issues with EASI accounts and PIC.

Today, Jeremy Buch (Microsoft), responded in a community thread where I posed the question about when EASI accounts would be supported. According to him, they are supported. There is a slight variation when adding a contact with an EASI account. Instead of adding the account as will@ personldomain.com, you add the account as will(personaldomain.com)@msn.com. This applies to adding the account from outside the MSN cloud or from your LCS implementation using Communicator. If you are using MSN Messenger, add the contact using the email address.

Tuesday, December 06, 2005

SharePoint Indexing Issue

I came across an interesting issue with moving the Indexing role to a new server in a SharePoint farm. I haven't seen anything online to suggest any solutions.

I have a small server farm with separate physical sql server. Due to the timing of availability of the second front-end server hardware, we are building the Index server first. We are enforcing SSL for our Portal. The Portal has been restored from a different environment using the spsbackup. I am able to add the new server to the farm. I am then able to move the Index and Job roles to the new server.

When I navigate to the Portal's searching and indexing page, I see an error message under each section (i.e. content indexes, content sources, search scopes). The error states cannot contact the indexing server and shows the server name of the server assigned the role.

After digging around and reinstalling SharePoint with no fix, I decided to add the default content access service account to the local administrator group. That fixed our issue in the search and indexing screens. We successfully rebuilt the indexes.

Now we were receiving a "path not found error" in the event log as the indexes were not propagating to the front-end server. We added the same service account to the local administrator group on the front-end server and the propagation completed successfully.

MS documentation states to add this service account to the Power Users group. This doesn't seem to be sufficient for our scenario. When I get some free time, I need to figure out if the issue is due to SSL enforcement or the fact the indexes are on a separate machine as the search indexes.