Lync Online supports presence interoperability with an on-premises deployment of Microsoft Exchange Server 2007 and Exchange Server 2010. The Lync Online service provides presence updates based on calendar information and Out of Office details that appear in Lync 2010 (see Lync Online Service Description for more). The presence information in Outlook is provided via the Lync Client and Lync relies on Exchange Web Services (EWS) and Exchange Autodiscover service to retrieve information for Availability, for Free/Busy, for Out of Office, and for Contact Search.
Note
When all of the following conditions are true ...
... the Lync Online user object in the Office 365 directory won’t have an SMTP address stamped. With no SMTP address available, the Lync Client can't query the on-premises Autodiscover and EWS endpoints to retrieve Free/Busy and Out of Office info. In this situation you must either
See also
Many SharePoint Online customers would like to be able to see Exchange Online data on their SharePoint Online pages (e.g their inbox or their calendar). First thought would be to use the built-in Outlook Web App Web Parts.
However – if you read the “Outlook Web App Web Parts” paragraph in the Exchange Online Service Description p. 46, you’ll learn that
“Exchange Online supports Outlook Web App Web Parts via the PageViewer control in Microsoft SharePoint Online and Microsoft SharePoint Server, or via manually configured URLs. Built-in SharePoint OWA Web Part controls will not work against Exchange Online”
Here is how you can display your Exchange Online data in SharePoint Online.
Step 1: Add the “Page Viewer” web part on a page
Step 2: View Outlook Web App segments in the web part
Notes
People who need to see or work with your SharePoint Online site content but who don’t have user accounts for your SharePoint Online environment are considered “external users.” External users might be vendors or customers, for example. With SharePoint Online, after you activate the sharing feature, you can invite an external user to your site just by sending them an email with an invitation (the invitation expires after one use).
Just follow the simple three steps in the article "Share a site with external users" to enable the sharing feature and then follow the steps in this article "Grant permissions for a site" to grant and restrict access to your site and content. This is called managing permissions and you do it by using security groups, which control membership, or by using fine-grained permissions, which help you control content at the item or document level.
The Office 365 terminology for external users is Partner Access Licenses (PALs). A PAL
Bonus Info
"In companies with Federated Identity set up, users can sign into Office 365 services using their Active Directory credentials. The corporate Active Directory authenticates the users, and stores and controls the password policy. With federated Identity, credentials are authenticated by on premises Active Directory Federation Services server and a logon token is obtained by the user so that the Office 365 sign-in service can verify them"
This all sounds very easy and digestible? No? Does the below diagram help? If no/maybe read on...
I'd like to think that I understand the concept of claims based identity, but because its such an important part of Office 365, I've always wanted to be able to explain the concept to others in an easy and digestible way. Luckily some of my colleagues wrote a book (Professional SharePoint 2010 Cloud-Based Solutions) in which they wrote the best explanation I've ever seen on the topic. In fact its so good I encourage you to read the below excerpt from the book (source: Donovan Follette - one of the authors blog post)
<excerptFromProfessionalSharePoint2010Cloud-BasedSolutions>
OVERVIEW OF CLAIMS-BASED IDENTITY
Claims-based identity is not a new concept, either in the practical world or within technology; it’s just that we don’t readily identify it as such in our day-to-day activities as easily as we can recognize it when it’s implemented with technology. Therefore, before we delve into claims-based identity within its technical implementation, this section looks at a practical scenario you have likely encountered, which you can use to help connect the dots to understand the concepts of claims-based identity when applied in technology.
Morgan arrives at the pharmaceutical conference eager and ready to participate for the next three days. She will have a triple role within the conference. First, since her company is a conference sponsor, she will spend part of her time in the company booth in the exhibit hall talking with conference attendees. Second, she is a conference speaker for one of the sessions. And, finally, she will be attending as many other sessions as possible for personal and professional enrichment.
Her first stop is at the registration booth, where Dean asks her to present a picture ID, which can only be a valid driver’s license or passport. Upon verifying her identity, the registrar provides her with a conference badge that includes her name, company name, bar code identifier, and three different colored ribbons to attach to the badge: a red exhibitor ribbon, a yellow speaker ribbon, and a white attendee ribbon. As you no doubt have surmised, each ribbon has different rights and privileges associated with it within the conference site.
Morgan tucks away her picture ID, securely attaches the ribbons to the badge, hangs it around her neck, and proceeds to the area to pick up the conference materials. At the distribution table, the person sees the white ribbon and provides a conference bag with all the materials for an attendee. Morgan then wants to see the booth area, so she visits the exhibit hall. Although it’s not yet open to attendees, the exhibit hall doorkeeper sees her red exhibitor ribbon and grants her access into the hall. After a brief visit with her colleagues, Morgan heads to the speaker preparation room to add the final touches to her presentation. Here again she is granted access, as she has the required yellow speaker ribbon.
This simple scenario illustrates the components of a claims-based identity system. There are specific identity providers (IPs) that the conference registrar will trust. In this case it is either a state department of licensing agency that has verified an individual’s identity and issued a driver’s license, or a government that has performed the verification and issued a passport. In either case the document they issue is considered an acceptable security token and can be validated by checking its specific security markings that warrant its authenticity.
The security token itself contains one or more claims — that is, statements about the subject, such as name, birth date, height, weight, photograph, and so on. These are called claims because they are supposedly true statements about the subject, but they are trusted only to the extent to which the IP that issued the security token is trusted. In other words, Morgan could have showed the registrar another security token — for example, her corporate picture ID card — that had almost all the same claims as her driver’s license. Even though this company-issued security token is truly authentic, and valid for Morgan in other contexts, it is not recognized by the conference. Although her company, as an IP, issued the security token with claims about her, the registrar could only accept trust statements about her when they were present in security tokens issued by state or government IPs.
A security token service (STS) determines the trust relationships it will have with other STSs in a claims-based identity system. Trust relationships can be established between an IP STS and a federation provider (FP) STS, sometimes called a resource STS (R-STS). The registrar in this scenario performs the role of the FP STS. The registrar verified that the security token provided for identification was authentic and from a trusted IP STS — and note his next action. In turn, he issued a brand-new security token: the badge, with its claims in the form of text, name, company, etc., and colored ribbons. It is this new security token that is trusted within the conference site (security domain) by all the different parties that will rely upon it. Essentially, the registrar accepted one security token, validated its authenticity, and then issued another security token scoped for another security domain, the conference. For Morgan, the original security token was no longer needed. Once the badge and ribbons were issued by the registrar FP STS, her driver’s license was put away and only her badge was required within the conference site.
Within the conference security domain, the relying party (RP) applications are the doorkeepers at the various session rooms, speaker preparation rooms, and exhibit halls. The RP cares nothing about whether the conference attendee showed a driver’s license or passport to the registrar. The RP needs only to trust the registrar FP STS, and relies upon it to provide the attendee with the conference badge security token, with its appropriate claims. Upon the basis of this trust, the RP can check the colored ribbon claim to grant/deny access to the appropriate venue. The additional claims on the badge are not required for access, but can be captured by handheld scanning devices to track attendance at each session and to collect leads by exhibitors in the exhibit hall.
Does this scenario sound familiar? This is claims-based identity in action, and it happens in many aspects of our daily lives; we just don’t readily recognize it — subject, trust, IP, STS, FP, security domain, security token, and claims are parts of everyday life.
Claims-based identity, therefore, is based on the ability of a security token service to encapsulate claims about a subject within a security token structure and issue the security token. Trust relationships are established between identity provider STSs, resource STSs, and relying party applications so that authenticity of an issued security token can be verified before being trusted by the relying party.
</excerptFromProfessionalSharePoint2010Cloud-BasedSolutions>
Thank you for reading to the very end of this (text heavy) post. I hope you now understand claims based identity a little better.
if you want the full enterprise voice experience as well as the benefits of the public cloud, then the Office 365 E4 service plan might be the right plan for you. In plan E4 Microsoft will provide the online versions of SharePoint and Exchange for you, but you must run your Lync Server either on-premises or have it hosted by a partner.
In case you plan to run your Lync Client in a virtualized environment, you might be interested in which features are supported by Microsoft for the Lync 2010 client in a virtualized environment.
In the below table Supported means “A configuration has been explicitly validated, or follows the industry best practice standards and is supported by Microsoft” and Not supported “Typically validation may or may not have been performed and, based on the results or lack of validation, this configuration is not supported by Microsoft” (Citrix will support Audio in a XenApp 6.5 scenario and all features in a XenDesktop 5.5 (and newer) scenario)
1 - Full Desktop Remoting: In this mode, the entire desktop is remotely accessed by using either session virtualization or VDI.2 - Application Remoting: In this mode, a given application or a set of applications that run on a remote server and are accessed without remoting the entire desktop.3 - Application Streaming: In this mode, an application is virtualized by sequencing it, and deploying the sequenced version in the data center, in such a way that users can access and run the application on their local device without installing the application.
If you organize an online meeting and you find yourself not being able to upload content and receive an error message, then...
In my meetings with customers and partners I'm often asked which SharePoint Online features are found in which Office 365 Service Plans.
Its possible to find a high-level comparison here (see screen shot below), but to provide a more granular view I've compiled six tables corresponding to each of the six capabilities in SharePoint; Sites, Communities, Content, Search, Insights, and Composites
Please note that things change and the below might not be accurate by the time you read it.
Sites
Communities
Content
Search
Insights
Composites
For the most recent information please see the current Product Use Rights (in the April 2012 version the SharePoint licensing info is found on page 50 and 51 - see screenshot below) and Service Description (E-plans and P-plan)
The Microsoft Office 365 Sign-In Assistant application will display a notification bubble in the Windows tray when the Office 365 password is about to expire.
The default duration of the notification bubble is five seconds. If you need to modify the duration (e.g. to increase the chance of the user noticing the notification) you can add a key to the registry or change a setting in the Control Panel.
Method 1: Add a key to the Registry
Method 2: Change setting in Control Panel
Password expiration notifications in rich clients in Office 365
If you've read the Microsoft Support article: "Access Denied" error, or the user is repeatedly prompted for credentials, when the user tries to access an Office 365 resource from a rich client application, you will know that you must download and install the latest version of the Microsoft Online Services Sign-in Assistant to enable password expiry notification. However in the same article you may also have noticed the below paragraph:
For users of Office 365 rich client applications (However, this does not include Microsoft Outlook), a notification balloon is displayed on user's desktops 14 days before the 90-day password expiration time-out to notify users that they have to change their password. Users are prompted every day after that until the user changes his or her password
What about Outlook?
Office 365 customers using managed (OrgID Based) accounts will not know when passwords will expire (if enabled for expiration). Further, Outlook’s behavior when the password expires is to go into a disconnected state, without notifying the user of what the problem is or what is required to resolve it. Opening Outlook and providing an expired password will continually prompt the user just as if they had mistyped the password.
Two hotfixes can be downloaded here:
After the hotfix is installed, Office 365 users who use Outlook receive a pop-up message in the notification area on the right side of the taskbar if their password is about to expire in a certain time period. The time period is set by administrators (default is 14 days).
For Office 365 users whose passwords have already expired, Outlook displays the following message to notify the user:
In either scenario, Outlook provides a URL for Office 365 users to update their passwords through their web browser. When a user clicks the link, he or she is redirected to the Office 365 portal to update his or her password..
See this Support article for more. See also:
Some Office 365 customers have a requirement to filter the Internet traffic.
This filtering can be done at the domain or IP address level. Microsoft strongly recommends that customer enable routing to the root domain names, such as *.Outlook.com, *.MicrosoftOnline.com and *.SharePoint.com instead of routing to specific IP address subnets.
It is possible to use IP-based filtering for the SSL content downloaded from Office365, as detailed in this article Office 365 URLs and IP Address Ranges. However, datacenter IP addresses are subject to change at any time, and Microsoft makes no commitment for updating or notifying the IP address ranges used by Office 365. Therefore it is highly recommended that if needed, customers configure filtering based on domain names and not by IP address.
Customers are asking if publishing AD FS endpoints using Microsoft Forefront Unified Access Gateway (UAG) is supported when using federated identities in Office 365.
In order to answer that question we'll need to touch on AD FS endpoints.
AD FS endpoints
AD FS endpoints are used to provide clients with access to federated applications. Endpoints will issue authentication tokens to clients, after successful client authentication. These endpoints are managed by the customer on their AD FS servers, and can be managed, secured and published individually through a proxy.
For accessing Office 365 online services, three distinct endpoints must be considered:
1. Passive Federation (WS-Fed Passive Profile):
2. Active Federation (WS-Fed Active Profile):
3. Basic Authentication “Active”:
So - can I use Forefront UAG for publishing AD FS endpoints?
Using UAG for publishing ADFS 2.0 endpoints is a supported scenario, but it only supports the WS-Federation Passive protocol. As seen above rich clients like Lync require communication to the AD FS 2.0 server through Forefront UAG using the WS-Federation Active protocol, which is not supported by Forefront UAG. The sign-in assistant does not help in this scenario because Forefront UAG blocks any communication using the active protocol.
When using Forefront UAG for publishing ADFS 2.0 to provide access to your Office 365 deployment, your users can use only applications that use passive requests, such as web browsers, and they must also install the sign-in assistant. They cannot use rich client applications that use the active protocol.