Friday, June 29, 2012

SharePoint Templates for Government

Microsoft Government SharePoint Templates for On-Premise or Online are now available at www.microsoft.com/GovernmentSharepoint
Why you should care? This is a great way to help your organization get more value from Microsoft technologies and see more possibilities with SharePoint.
  • Providing your organization a starting place to see the possibilities with SharePoint, a great solutions platform.
  • Jumpstart your organization to use SharePoint for more than just document libraries by identifying a couple templates that they might find useful.
  • This offers examples of great out-of-the-box capabilities to compose end to end business solutions. Many templates are designed for SharePoint 2010 AND SharePoint Online!

Monday, June 25, 2012

Microsoft Purchases Yammer

Today we had a major announce for Office 365 and SharePoint which I am very excited about. Microsoft announced that we had reached a definitive agreement to buy Yammer, a leading provider of enterprise social networks.
Why am I excited about this?
I think we have a great partner portal and social computing solutions in SharePoint Online today; however the addition of Yammer makes our story even stronger and resilient. Yammer is a best-in-class enterprise social networking solution and Microsoft plans to utilize Yammer with SharePoint, Office 365, Dynamics and Skype. Microsoft has stated they do not plan to disrupt Yammer’s current business and there will be focus to bring the Yammer services into the products I just mentioned.
It is my job to talk with customers about all of our Office 365 services and I had several customer conversations this year where having a solution like Yammer would have been very helpful.
With Yammer, you have a simple, clean, direct user experience where group workspaces and collaboration areas can be quickly created with tons of business social solutions such as profiles, organization charts, praise, question, messaging, feeds, announcements, member directories, expertise management, leaderboards, events, polls, shared group areas, content collaboration, and tons of additional solutions.

Friday, June 15, 2012

SharePoint Online Partner Access

Introduction
I have to say that Partner Access is probably one of the best kept secrets for SharePoint Online in Office 365. Additionally for customers who have SharePoint and want to extend it to people outside of their organization, SharePoint Online provides a unique solution for partner access which is different that on-premise. I can honestly see scenarios, with financial justification, where organizations may keep portions of SharePoint implementation on-premise while moving completely over to SharePoint Online just to support extranets. I still believe that a majority of SharePoint workloads can be moved to the cloud (as I captured in this blog) but partner access is something that many organizations what to do.
Some of the most common reasons why I have seen requests for Extranets/Partner Portals with SharePoint are:
  • Support Business-to-Business and/or Business-to-Customer initiatives
  • Personnel who travel or are in the field
  • Geographically dispersed teams
  • Employees/Partners Teleworking both connected and disconnected
  • Support real time unified communications
  • Secure and centralized communications with external entities
This typically translates into the following:
  • Extranet Site for Partner Organization - Dedicate site with features driven specifically to facilitate better coordination with partners.
  • Tactical Partner Site - There is an immediate need for collaboration area to support a business activity with external people to the organization.
  • Community of Interest - There is a need to provide focused support, collaboration and knowledge sharing for a target group of organizations and individuals.
  • Partner/Customer Support - Need the ability to interact with partners, customers or constituents in a secure environment.
  • Etc.
Challenges with Extranet Deployments
First I want to say that deployment of SharePoint Extranets solutions can be implemented very efficiently and securely, however there are a lot of hurdles that organizations must overcome. In many cases, they are not even technical. Here are some of the most common:
  • Infrastructure and Deployment - Managing an extranet environment requires a lot of security and configuration management best practices. This is mostly because you are now deploying SharePoint into the DMZ so it can be accessible from the outside. I have seen organizations punch holes through the firewalls which again require new security configurations and controls.
  • Ease of Management - Organizations are challenged to have an environment that they can quickly use with a partner in time of need.
  • Agility, Scalability and Service Level Agreements - The deploying organization is responsible for building an environment that scales to changing business requirements. Provisioning and maintaining an environment that is highly available can be expensive. Additionally providing an environment that needs to potentially be globally available.
  • Access and Security Management - Managing access control of individuals to only have access to the extranet is important. In some cases, organizations use Active Directory to give external users access which can create a lot of new security controls to be put in place. None of these controls have anything to do with SharePoint. For instance, new security policies need to be put in place to ensure that external partners have their accounts removed when they no longer need access.
Extranet Architectures
There are some very common solution architectures for implementing SharePoint Extranets on-premise. Here is a great reference that you should read – http://technet.microsoft.com/en-us/library/hh204611.aspx. I highly recommend reading the topologies diagram. I am not going to go into the pros/cons of each ones of these architectures as they have been pretty well documented.
Below is what is referred to as an Edge Firewall where direct access is provided from the Internet.
image
This is what is called a Back to Back Perimeter which basically standing up the entire SharePoint Farm in the DMZ.
image
Finally another popular called a Split Back to Back where some servers are deployed in the DMZ while other server roles remain inside the internal network. This is commonplace when SQL is not deployed in the DMZ.
image
Benefits of the SharePoint Online Partner Sites
This approach literally changes the way we implement a solution to work with Partner Sites. The benefits of using SharePoint Online for Partner Sites are immense.
  1. Highly available, scalable and accessible architecture – No more having to build and manage highly available SharePoint environments as you can rely on the cloud to provide it to you and your partners.
  2. No more AD Accounts for Partner Users – I know perfectly well that SharePoint support Forms Based Authentication (FBA), LDAP directories, etc. but all too often I have seen organizations just use their AD which get the security team nervous when there is no plan in place to manage these accounts. With SharePoint Online we have the ability to use Partner Accounts (to be explained in next section).
  3. Immediately provision new secure sites – It is really quick and easy to set up a partner site as I am about to show you. Instead of spending weeks standing up a new SharePoint Extranet farm, an Office 365 tenant can be purchased and Partner Sites can be stood up in minutes.
  4. No software and hardware in the DMZ – This is a huge plus for the security team as you just made their lives easier. Plus external users never come into the organization, they always go to Office 365.
What are SharePoint Online Partner Accounts?
You may be wondering what are SharePoint Online Partner Accounts. A SharePoint Online Partner Account is a solution for Office 365 whereby a user can use Windows Live ID to authenticate themself to your SharePoint Online tenant. For example, if they person email address is smith@xyzcompany.com, all they need to do is register that email with Windows Live and they will create a password that they know. Then all you need to do is invite smith@xyzcompany.com to a SharePoint site and they will use their own email address and password to authenticate to SharePoint Online.
No more managing external accounts in any type of directory services solution (AD, FBA, etc.). All you do is control what the user is authorized to do with SharePoint permissions.
Steps for Creating a Partner Site in Three Steps
The steps for creating a partner site are extremely simple.
Step 1 - Allow external users
First we need to go into the SharePoint Online administration center and allow SharePoint Online to have external users. You do this by going to the ribbon and selecting Manage External Users.
image
Then in the prompt, change the selection value to Allow.
image
Step 2 – Create a New Site Collection
Next we need to create a site collection for our partners.
image
Then once the new site collection has been created, I select it and in the Ribbon I select “Add Support Partners”.
image
Then in the prompt I selected the company site administrator.
image
Step 3 – Activate External User Invitation Feature
This is one step which could use some automation as this is a common step that people miss. If you think you are ready to start adding partner accounts, hold up. To add an external user you will use the Share Site button in the Site Actions Menu.
image
However when you go here, and try to add an external user by typing in an email address that is not in your domain, you will receive an error.
image
To resolve this, you must go to Site Collection Administration, go to Site Collection Features and activate the External User Initiations feature.
image
Now when you go Site Actions >> Share Site you will notice that this screen has changed. You will now be able to type in email address from another domain and invite that user to the SharePoint Site.
image
Steps for Inviting a User
The steps for inviting a user are extremely simple.
Step 1 – The Invitation
First, in the Share Site prompt, type in an email address of someone you like to invite.
image
You will receive a confirmation that it has been sent.
image
Step 2 – Confirm the Invitation
Note – if you are doing this for internal testing, close all browsers before continuing and you may need to delete your internet cache because you will be logging in with a different account.
The invitee will receive an email like the following. In this case it went to my Yahoo email address. The invitee will need just press the accept button.
image
The invitee will be taken to this screen where they will need to log in. The invitee will need to click on the Windows Live Hotmail link on the left. This will take them to a page to sign in with their Windows Live ID, which is tied to the email address I invited.
Note – if the user accidently clicked on the Microsoft Online Services ID link, they will be redirected to the correct Windows Live ID login screen they can click on a link that will take them to the appropriate sign in page.
image
On this screen the invitee must enter their email address. This should be the email address that was invited.
image
Now the user will be brought into SharePoint Partner site using their Windows Live ID.
image
Step 3 – Administration (Optional)
To administer this external user, you just go to the SharePoint group that was assigned to the user when they were invited.
Note - that the user will not appear in the group until they accept the invitation.
image
Here is the profile of the invitee. As you can see it is tied to the Yahoo email address that was used.
image
In Closing
If you are an experience SharePoint professional you will know this is a game changer; and if you are not, you should see how easy this is to implement.

Sunday, June 3, 2012

Office 365 Government Community Cloud

There was a big announcement this week for Office 365 and for our Federal Customers. Office 365 now has a US Government Community Cloud - http://blogs.office.com/b/microsoft_office_365_blog/archive/2012/05/30/announcing-office-365-for-government-a-us-government-community-cloud.aspx
What does this mean? On top of providing industry standards for privacy and security such as ISO 27001, SAS70 Type II, EU Safe Harbor, HIPPA, etc., Microsoft will be providing a FISMA certified cloud environment that is segregated to US Government organizations.
It is important to know that the Office 365 Multi-tenant cloud is just as secure as the Office 365 US Government cloud however there is not a “one size fits all” solution. US Government agencies just have different policies they must to adhere to and having US Government only cloud allows them to move forward. For instance, there are different US Federal background checks of personnel that are required.
Here are some other notes you should be aware of:
  • Right now, this cloud is targeted to US Government agencies with a .GOV or .MIL domain extensions. As we already know data is segregated between customers, but there is an additional layer of segregation for government only customers.
  • The ITAR controls are not available on the US Government Community Cloud. ITAR is only available for Office 365 Dedicated which also FISMA security controls.
  • Purchase of the US Government Community Cloud is done through an EA.
  • Pricing of the Government Community Cloud is the same as the Multi-tenant cloud with additional government discounts; contact your account executive for details.

Thursday, May 3, 2012

FISMA Update for Office 365

Another win for Office 365 and security! Up until now Office 365 Dedicated with ITAR had the ability to meet FISMA. Now Office 365 Enterprise Services (the multi-tenant cloud) has a FISMA authority to operate (ATO). Please review the following for more details about this announcement - http://blogs.office.com/b/microsoft_office_365_blog/archive/2012/05/03/fisma-security-certification-office-365.aspx

Monday, April 23, 2012

Office 365 Federation Overview

Background
I keep on neglecting to finish this blog post, so I am going to crank this out. I recently federated a lab environment with Office 365 and I wanted to share the resources and some of my lessons learned. Actually federating with Office 365 is a pretty straight forward task.
In this blog I will capture the major steps I took, capture some lessons learned, and give you the resources you need to get there.
Authentication Options
With Office 365 you have a few authentication options:
  • Microsoft Online IDs – These are cloud based IDs. They are best for small organizations. Users will have a different log-in a different username and password; so there is no Single Sign On experience for the user accessing cloud services. If there is a two factor authentication requirement, that cannot be supported using this authentication method. You do have the option to bring in your corporate GAL that is managed through on-premise Exchange with the synchronization tool.
  • Federated IDs – This is when you decide you want to provide a Single Sign-On (SSO) experience with Office 365. This is enabled through Active Directory Federation Services 2.0 (AD FS 2.0) to be installed on premise. Implementing federations provides the ability to support two-factor authentication and enables co-existence/hybrid scenarios.
  • External User Authentication – It is worth mentioning on the side that organizations want to bring in external users and partners to collaborate with them. SharePoint Online supports the ability to create a partner cloud account that is within Office 365 or allow users to authenticate to SharePoint Online with Windows Live ID. The Windows Live ID is very appealing because external users can use whatever email address and password they have to access SharePoint Online.
Major Steps for Federation
This is all actually very well documented in the references I am providing at the end blog. The steps for federating with Office 365 are:
  • Plan and Prepare
  • Deploy Active Directory Federation Services
  • Establish a Relying Party Trust with office 365
  • Set Up Active Directory Synchronization
  • Activation of Services for Users
image
Plan and Prepare
First thing you really need to sit down, read the materials and come up with execution plan. It is not brain science however knowing your requirements and how people will access Office 365 services will directly affect how you deploy your federation services.
Here are some things to think about:
  • Multiple Domains - If you have multiple domains and sub domains you should spend some extra time planning trusts with AD FS.
  • Multiple Forests - If you have multiple active directory forests, synchronization and authentication is not currently supported today with Office 365 Multi-tenant. To get around this you can consider consolidating forests or only deploy Office 365 with a primary login forest.
  • Deployment Readiness Tool – As part of running the Deployment Readiness Tool, you may have some changes as it will check email domains, AD (required attributes, remove special characters, etc.), networks, DNS, etc.
  • DNS – Part of the configuration will require DNS configuration and you need to make sure you are working with a person in your company or organization that can make these configuration changes.
  • Access Outside Corporate Network – Need to understand how users will need to get access to your environment. If they will be accessing from home, public areas, etc. you will need to need to deploy proxy servers in your DMZ (will discuss later).
  • Two-Factor Authentication – If you need to support two-factor authentication some additional configurations (will discuss later).
  • Certificates – You will need SSL and Token Signing Certificates. I highly recommend getting all of this worked out from a logistics perspective before you start, otherwise you will be waiting for people to get things for you.
  • Administration Rights – Note that many of the configuration steps require domain administrator rights. You will need to get this person involved and they need to participate as part of the configuration and installation of the service.
Approach
Honestly every plan to implement this will differ to some degree based on the current state of your current infrastructure. The link below entitled “Office 365 Single sign-on: Roadmap” along with the “Office 365 Deployment Guide” are your best resources for configuring federation with Office 365.
Federation
Initially there are a couple resources that will need to be added such as:
  • AD FS 2.0 – Must be installed on-premise to support federation. It is recommended that you add more than AD FS 2.0 server for redundancy purposes and load balance them.
  • Directory Synchronization Tool – This tool will synchronization active directory information to Office 365 to support the GAL. The reason why you need to do this is because AD FS only helps with the ability to authenticate, it will not actually allow you to find other users in your organization like in Exchange or SharePoint Online. This cannot be installed on a Domain Controller or AD FS server.
So minimally you will need something like this.
image
If you need to be able to support users to access Office 365 services when outside the corporate network, you will need to add some additional resources to support the federated authentication.
Federation with External Network Access
The most common documented one is to install AD FS 2.0 Proxy Server(s) in the DMZ (depicted below). Requests come in externally to the proxy servers and then sent through to corporate network to authenticate against AD.
image
An alternative is to use something like Microsoft Forefront Unified Access Gateway (UAG) for supporting users to access federated Office 365 services when outside the corporate network.
Strong / Two-Factor Authentication
Another common requirement is the need to support two-factor authentication along with federation. If a user is logging in on the corporate network or with a domain joined machine, you can utilize the existing infrastructure to meet this requirement and no further deployment is required except for AD FS 2.0 (which provides the single-sign on experience to Office 365). However if need to extend support of two-factor authentication for users accessing Office 365 services from non-domain joined machines additional configuration is required.
One solution is to use Microsoft Forefront Unified Access Gateway (UAG) SP1 to provide two-factor authentication for these users whom need to access Office 365 services from non-domain joined machines. UAG provides several solutions for two-factor authentication and direct access. One thing to be aware of is UAG supports two-factor authentication for passive federation endpoints (i.e. web clients such as SharePoint Online and OWA). UAG cannot support two-factor authentication for active federation and basic authentication endpoints (i.e. Outlook client, Lync client, ActiveSync). This means providing strong authentication with UAG will be limited to using Office 365 web clients. In my opinion this is not a major limitation for businesses utilizing Office 365 services because typically the only thing that IT will for non-domain joined machines are browsers. Even with bring your own device policies, organizations will typically not support down to the rich client; nor do they really need to.
Another potential solution is to use AD FS 2.0 to enforce strong authentication by modifying the AD FS 2.0 proxy logon page to add two-factor support. This would entail adding extra fields for the users to enter extra factors for authentication. Doing this would require integration with whatever two-factor authentication servers/services that is in place.
In summary, UAG is a good solution for accessing Office 365 service when supporting two-factor authentication for external, non-domain joined machines.
Pilot Single Sign On
Additionally you may be interested in piloting users with single sign-on authentication. There is a great article in the references in this blog that explains how to do this. It is really straight forward. First you will notice that you can always add single sign-on later. You have the ability to create your Office 365 tenant using cloud IDs and when you are ready you can transition over to federated authentication with active directory. Second thing to note is you can even create scenarios where some users authenticate to Office 365 services using a federated account while other users only use cloud based IDs. This can provide you some flexibility in potentially how you want to manage accounts.
References/Resources

Saturday, April 7, 2012

Office 365 Dedicated Service Description Update for April 2012

The Office 365 Dedicate service descriptions have been updated for at in April 2012. Go here to get the service descriptions:
  1. Office 365 Dedicated Service Descriptions - http://www.microsoft.com/download/en/details.aspx?id=18128
  2. Office 365 Dedicated with ITAR Service Descriptions - http://www.microsoft.com/download/en/details.aspx?id=23910
To get a quick description of all the changes read the document called “What's New in the Latest Service Update_Office 365 Dedicated Plans_April 2012.docx” which captures all the changes in the services.
Here are some changes to take note of:
  • Mailbox Auditing Reports
  • Hosted voicemail services
  • More streamlined process for approving SharePoint Full Trust code
  • Lync data access and IM archiving
  • Enterprise Voice updates
There are some others but these are some highlights.
Note if you are looking at Office 365 Multi-tenant (meaning the shared Office 365 cloud) please review those service descriptions here as they are different (http://www.microsoft.com/download/en/details.aspx?id=13602).