When you have a *nix crowd to cater for in your Office 365 or Lync deployment the following information will be useful:
– You can use the SIPE plugin to enable your *nix users to chat on O365 or Lync servers
– There’s a client-side bug in pidgin-sipe v. 1.18.2 where it used the user’s SIP address entered as the login address being presented to the ADFS server regardless of what was entered into the console
– This was fixed upstream in v 1.18.4
– This bug is invisible when the user has the same UPN and SIP address
– On the AD FS server side a workaround would be to allow extended attribute lookup during logon (f.x. use the ‘mail’ attribute if it matches the SIP address)
Note: The Alternate Login ID feature is not compatible with Exchange Online Hybrid Deployments. Customers that wish to configure Exchange Online Hybrid Deployments with Office 365 must not configure Alternate Login ID.
The Alternate Login ID feature may impact various other Azure AD and Office 365 scenarios including:
- Office 365 ProPlus activation may require explicit sign-in
- InTune customers using SCCM connectors may require additional configuration.
Configuring Alternate Login ID [for AD FS 3.0]
The SIPE project
How present are you?
Office applications that integrate with IM applications and generate a presence accomplish this by contacting the IM application that is listed as the default as per the corresponding registry key (DefaultIMApp).
This is frequently populated with the name of the last IM application that was installed on the machine.
In some cases the IM application even monitors the registry key and overrides any changes made to the default IM application by other IM applications (shades of IE/Firefox/Chrome default browser ping-pong).
From the perspective of the IM application this may sound like a perfectly logical idea as it is making sure it is the default. If you are trying to either integrate several different IM applications on the same workstation or you want to select a specific application yourself to be the default for any presence information in Sharepoint, Outlook, etc. then it becomes a real headache when one application insists on setting itself as the default regardless of your wishes.
The net effect will be that only the default IM application will count as a valid Presence for the user, if the user isn’t active in that application then the user doesn’t generate any presence in Sharepoint or Office.
- the user will be signed in to one IM application on the workstation (f.x. Lync 2013 or Skype for Business)
- another IM application has overwritten the HKCU\Software\IM Providers\DefaultIMApp registry key (f.x. Jabber or Communicator 2007)
- that IM application isn’t currently active on the workstationEnd result: The user doesn’t generate a presence even if he or she is active on the Lync or Skype application
This key specifies the IM application Office integrates with when it starts up
How Office integrates with an IM client application
When an Office 2013 application starts, it goes through the following process to integrate with the default IM client application:
- It checks the registry to discover the default IM client application and then connects to it.
- It authenticates with the IM client application.
- It connects to specific interfaces that are exposed by the IM client application.
- It determines the capabilities of the currently signed-in user (local user), including getting the user’s contacts, determining the user’s presence, and determining the user’s IM capabilities (instant messaging, video chat, VOIP, and so on).
- It gets presence information for the local user’s contacts.
- When the IM client application shuts down, the Office 2013 application silently disconnects.