Category Archives: SharePoint

Configuring Licenses in SharePoint 2013

One of the most frequently asked questions when I was working with SharePoint 2010 was “Can we have both standard and enterprise client access licenses (CALs) in the same SharePoint Farm?”.   The answer was always yes but with a follow on discussion.  The discussion dove into the challenges for an organization to track and ensure that the users licensed with a standard CAL were not accessing enterprise CAL features.   In SharePoint 2010 organizations were limited to setting up site collections and sites around CAL types.  This type of architecture introduced may issues and blocked some people from easily collaborating with each other.

In SharePoint 2013 a new concept was introduced that enables an organization to define license groups in AD and then map them to specific license types in SharePoint.  This new model has made it much more easier for an organization to track SharePoint licenses, maintain license compliance, and provide better collaboration capabilities to end users.

The video below walks through the simple process of configuring SharePoint 2013 licensing.

 

For more information you can check out an article published on TechNet called Configure Licensing in SharePoint Server 2013.

SharePoint 2013 in Windows Azure

Today a co-worker forwarded an interesting video to me that I thought I would share.  This video shows how a SharePoint 2013 infrastructure can be deployed in Windows Azure and can quickly scale to support additional workload.   You can checkout the performance of the SharePoint 2013 site running on Azure by visiting http://con-web.cloudapp.net/

Could your organization benefit by hosting SharePoint in Azure?

Free Download: SkyDrive Pro Client

When SharePoint 2013 and the new SharePoint Online was released there was a new capability included called SkyDrive Pro.   This capability is similar to the consumer SkyDrive solution, however, it is based upon SharePoint and can be managed by the enterprise organization.

Up until now to use SkyDrive Pro you needed to deploy Office 2013 on the desktop.  Although many customers have Enterprise Agreements or are Office 365 customers, they are just not quite ready to deploy Office 2013.   This means that they can’t take advantage of the SkyDrive Pro capability.

Recently Microsoft released a free standalone SkyDrive Pro client for Windows that can be installed side by side with previous versions of Office.

Visit the Microsoft Download Center to learn more and to download the SkyDrive Pro Client.

SharePoint 2013 Development Overview

SharePoint 2013 and SharePoint Online provides a new modern application development model. This new model provides a scalable way to build SharePoint solutions using standards based technologies.

Modern SharePoint apps are built in a way that allows the organization to choose how and where to host the apps. This model also makes it much easier for an organization to move between SharePoint on-premises and SharePoint Online.

To help explain the different development options I have created a SharePoint 2013 development overview slide deck.  The intent of this deck is not to teach a person how to do development, but instead to outline the different development models available.  With this information an organization can make a well informed decision on how to approach custom development with SharePoint.

Get Started Building Apps for Office 365, Office 2013 and SharePoint 2013

If you are interested in developing apps for Office 365, SharePoint 2013 or Office 2013, grab the new Office Developer Tools for Visual Studio 2012 here:  http://www.microsoft.com/visualstudio/eng/office-dev-tools-for-visual-studio

Once installed you will find two new project templates in Visual Studio;  App for Office 2013 and App for SharePoint 2013.  These two templates provide the necessary plumbing to help you get started building new apps quickly.

Building custom solutions using SharePoint 2010 required a local installation of the server software.  The new app model for SharePoint 2013 has changed the way developers will build out their environment.  Instead of using a local installation of SharePoint 2013, app developers can use a remote SharePoint 2013 server or SharePoint Online tenant.  This new capability reduces the complexity of the developer workstation and reduces the amount of memory and software that needs to be installed.  MSDN has a great article explaining how to setup a development environment for building apps for SharePoint on Office 365.  I would recommend that developers build solutions using the new SharePoint app model instead of the traditional server-side object model based farm or sandboxed solutions.

Server-side object model based farm or sandboxed solutions can still be created if necessary. If you plan to build solutions using the server-side object model then you will still require a local installation of SharePoint 2013.   Because of this requirement, the developer workstation will need at least 16GB of RAM;  24GB is recommended.  Steps to setup a local instance of SharePoint 2013 for development can be found on MSDN here

Organizations that are using SharePoint 2013 on-premises can use their SharePoint instance for development.  Steps for configuring your development environment and your on-premises SharePoint environment for creating SharePoint apps can be found on MSDN here.

Microsoft has provided very good documentation and samples for developers to learn how to build apps using SharePoint 2013.  I would recommend starting with the article titled Build apps for SharePoint.  Additional documentation and samples can be found at http://msdn.microsoft.com/sharepoint

Don’t forget that apps you create for SharePoint 2013 can be published to the SharePoint store where you can make money!   You can learn more about publishing your apps by reading the MSDN article titled Publish apps for SharePoint.

Leave me a message below or using the Contact Me! link above if you have published a SharePoint app in the store.  I am very interested to see what solutions are created.

New Visio Stencils for Office 2013 Server Products

Microsoft has made new Visio stencils available for Exchange 2013, Lync Server 2013, and SharePoint Server 2013.  Download links are below:

This stencil contains more than 300 icons to help you create visual representations of Microsoft Office or Microsoft Office 365 deployments including Microsoft Exchange Server 2013, Microsoft Lync Server 2013, and Microsoft SharePoint Server 2013.  Download here.

This stencil contains Exchange 2013 specific icons to help you create visual representations of Microsoft Exchange 2013 deployments, including on-premises, hybrid, and Office 365. Download here.

SharePoint 2013 + Exchange 2013 = Site Mailboxes

When an organization deploys the new Office 365 or chooses to deploy SharePoint 2013 and Exchange 2013 on-premises they can use a new feature called a site mailbox.

A site mailbox is a shared Exchange mailbox that is associated with, and managed by a SharePoint site. A site mailbox provides teams a more integrated way to capture not only documents but also team communications.

Creating a new site mailbox is as easy as creating a list or document library.  Within the new SharePoint 2013 Site Contents section an option exists to add a new app.

All lists, libraries and other applications are now called “apps” within SharePoint 2013.  Clicking on the add an app option will present you with the standard SharePoint list and library templates along with any other additional applications that have been installed within the SharePoint environment.  One of the new applications is called a Site Mailbox.  Choosing this item will create an Exchange 2013 mailbox and associated it directly with your SharePoint site.

Once the mailbox is fully provisioned, which may take several minutes, any contributor on the SharePoint site will have access to the new shared mailbox.  When the provisioning of the mailbox is completed, each of the contributors on the site will receive an email message with information about the new site mailbox, including its email address.

After creation a link to the site mailbox will be automatically added to the quick launch navigation bar on the SharePoint site.  Clicking on the link will launch the site mailbox using the Outlook Web Application.  Contributors of the SharePoint site will be able to read, reply to, or create new email messages directly from the site mailbox.   Email messages that are sent using the site mailbox will be kept in the site mailboxes sent items folder, however, the from address will always be the user who sent the email and not the site mailbox address.

Site contributors that are running Outlook 2013 will automatically see the new mailbox show up in their Outlook client giving them quick access to both the site mailbox and the document library on the site.  Outlook provides that one single client access into both email content and documents stored within SharePoint.

In the image above, you can see that Karen B. has a primary mailbox in Outlook 2013 and a Northwind Traders site mailbox.  From that site mailbox she can quickly have access to both the emails and documents located on that site.  If Karen B. is removed from having contributor permissions on the SharePoint site, she would also lose access to the site mailbox.   As a result, the Northwind Traders mailbox shown in her Outlook 2013 client would also automatically be removed.

When the SharePoint site is deleted a process will ensure that the site mailbox is also deleted from Exchange.  If you choose to use a site mailbox you will want to think about both the data lifecycle for the SharePoint content and Exchange mailbox content.

The tighter integration of Exchange with SharePoint is providing new and exciting collaboration capabilities across the Microsoft productivity platform.  Learn more about Site Mailboxes on TechNet.

SharePoint 2013 using Azure ACS – Part 2

It has been some time since I wrote part 1 of this post and I was hoping that I would have part 2 completed and online within a week.  Due to a very exciting announcement from one of my customers I have been very busy and was unable to get back to completing this article.   I also have been distracted with the new multiplayer game PlanetSide 2 and my old standby World of Warcraft (yeah… I am one of THOSE people).

After reviewing a previous article I wrote regarding Azure ACS and SharePoint 2010, I have decide to not complete my article related to SharePoint 2013.   The reason is that the second part of this series is exactly the same in SharePoint 2013 as it was in 2010.  The only change that has occurred is that the sign-in URL for Azure ACS has changed.   Therefore, I am going to reference the original article below and then highlight the change that need to be completed in order to complete the configuration for SharePoint 2013.

To complete the Azure ACS SharePoint 2013 configuration start with step 1 located on this previous Azure ACS article.

In step 3, you will need to make a minor modification to the PowerShell script.  There is a PowerShell variable called $signInUrl that needs to be set to “https://<namespace>.accesscontrol.windows.net/v2/wsfederation” where <namespace> is the namespace you defined in step 6 in part 1 of this article.

Complete the rest of the steps in the Azure ACS article to configure a SharePoint 2013 web application to use Azure ACS for authentication.

SharePoint 2013 using Azure ACS – Part 1

A while back I wrote an article about using Windows Azure Access Control Services with SharePoint 2010.  That configuration enabled a scenario where users could log into SharePoint with a Windows domain, Microsoft , Google , Yahoo! or Facebook account.  Since writing that article a lot has changed; the Windows Azure Portal has been updated, a new version of SharePoint has been released, and other related changes have occurred.

One major change is that Microsoft is no longer charging for the use of Windows Azure Access Control Services (ACS).  This means you can use one of the external authentication providers with your on-premises SharePoint installation for free!  Utilizing Azure ACS with SharePoint 2013 can greatly reduce the support costs for managing accounts in an extranet environment.  This will also allow users to utilize an account they already have instead of having to create or manage additional login credentials.

In this post I will outline how to configure Azure ACS with SharePoint 2013.  This configuration will be very similar to the SharePoint 2010 configuration I previously documented.  I assume that you already have a working and stable SharePoint 2013 server farm configured.

For this demo I have ensured that the Request Management service is not started. In this demo I only have a single SharePoint server in my farm, therefore I do not need request management.

I am also assuming that you have signed-up for access to Azure services at http://www.windowsazure.com.  A Windows Azure account is required even though Azure ACS is available free of charge.

To get started, we need to login to the Windows Azure portal and configure a new Azure ACS namespace used for SharePoint 2013 authentication.

  1. Go to http://www.windowsazure.com and click on the portal link located in the upper right to log into the management portal.
  2. Management of Windows Azure ACS has not yet been added to the new Windows Azure portal.  We need to switch back to the previous version of the portal by clicking on our email address (or username) located in the upper right of the web site and then choosing the previous portal menu option.
  3. At the bottom of the left menu click on the Service Bus, Access Control & Caching option.
  4. On the upper left column choose Access Control under the Services heading.
  5. In the top menu click on the New option in the Service Namespace group.
  6. In the dialog window that opens, fill in the Namespace field with any string value of your choosing.  Click on the Check Availability button to ensure it is available.  You will also need to choose the Country/Region for your ACS service and the subscription associated with your account.  Although Azure ACS is free you still need to have a Windows Azure subscription.  Click on Create Namespace.  Note:  MSDN users get Windows Azure subscription as one of their benefits.
  7. Windows Azure will begin to provision and activate your Windows Azure ACS service.  In the main window of the portal you should see your namespace listed along with a status of Activating.  Once the service status changes to Active you can proceed to step 8.  It may take several minutes for the service to activate.
  8. Select your namespace service from the list and then click on the Access Control Service option in the Manage Access Control grouping in the top menu bar.  This will take you to the Access Control Service management console.   If the Access Control Service option is not enabled you have either not selected your namespace in the main list or your service is still activating.
    image
  9. In the Access Control Service console click on the Identity providers option in the left menu.  This is where we will select what identity providers we will make available to SharePoint.  In this demo I will be add Microsoft Account (Windows Live ID), Google and Yahoo!.  I will not be adding Facebook authentication in this example because it requires additional configuration on the Facebook website.
  10. On the identity provider page you will see that Windows Live ID has already been added.  Click on the Add link to add additional providers.
  11. Under the Add a preconfigured identity provider section choose Google from the list and then click the next button.
  12. On the Login Page Settings accept the default values and click on the Save button.
  13. Repeat steps 11 and 12 but instead choose the Yahoo! provider.
  14. Now that the identity providers have been selected the next step is to configure a relying party application.  This is the first configuration we make that relates to our SharePoint environment.  On the left menu click on the Relying party applications option.
  15. On the Relying party applications page click on the Add link.
  16. Fill in the Add Relying Party Application form using the following guidance and then click on the Save button.
      • Name –  This is the top level domain for the SharePoint web application you are going to create.   Example: Fabrikam.com
      • Mode –  Choose Enter settings manually
      • Realm – This is a unique URI used to link this provider to a SharePoint provider definition.  Chose your own value based upon the format of this example:  urn:fabrikamspdemo:spub
      • Return URL – This will be the URL of the SharePoint web application you are creating with /_trust/default.aspx appended.  We will use SSL on our SharePoint site, the URL is specified with HTTPS as the protocol.  Example: https://www.fabrikam.com/_trust/default.aspx
      • Error URL – leave this blank
      • Token Format – Select SAML 1.1
      • Token Encryption Policy – Select None
      • Token Lifetime –  Set this value to 1200.  (Please review this MSDN article on how the SAML token lifetime and the SharePoint  TokenLifeTime settings can impact how frequently a users is prompted to log back in when using Windows Azure ACS)
      • Identity Providers – Choose all of the providers we configured above.
      • Rule Groups – Check create new rule group
      • Token Signing – Leave this as the default.
  17. A rule group defines how claims are passed from the identity provider to SharePoint.  You need to update the default rule group created in step 16 with the proper rules.  Click on the Rule groups option in the left menu.
  18. Click on the Default Rule Group for your relying party application.
  19. Click on the Generate link located above the rules section.  This will allow you to automatically generate the necessary rules for each of the identity providers.
  20. Select all of the providers and choose Generate.
  21. Click on the Save button under the Rule Group Details section.
  22. To allow secure transmission of the SAML token we need a x.509 certificate.  For this example we will generate our own self-signed certificate.  For a production environment you may want to procure a certificate from a trusted certificate provider.  You will need the MakeCert utility to create the certificate.  You can download that utility from here.A. Extract the MakeCert utility into a temporary folder.  (example c:temp).B. Open a command prompt as an administrator and change to the location where you extracted the MakeCert utility.C. Run the following command, replacing <service_namespace_name> with your unique service namespace.  Your namespace can be seen in the top gray bar of the Access Control Service Portal.

    makecert.exe –r –pe –n “CN=<service_namespace_name>.accesscontrol.windows.net” –sky exchange –ss my

    Note:  the above command may have line wrapped due to space limitations.  The command should be entered in completely on a single line.

  23. The certificate created in step 22 needs to be exported so it can be uploaded into Windows Azure.  The following steps will export the necessary certificate:
    • A. In the command prompt opened in step 22, type MMC and press enter.  This will launch the Microsoft Management Console.
    • B. In the MMC Console click File and then click Add/Remove Snap-in.  Double click on Certificates.
    • C. Select My user account and then click finish.
    • D. Close the Add Standalone Snap-in dialog by clicking on OK.
    • E.  In the console double click Certificates – Current User.
    • F.  Expand Personal and then expand Certificates.
    • G.  Right click the certificate you created in step 22.  Choose All Tasks and then click Export to open the certificate export wizard.
    • H.  Click Next on the first page of the Certificate Export Wizard.
    • I.  Select Yes, export the private key and then click Next.
    • J.  Select Personal Information Exchange format and then click Next.
    • K.  Enter in a password to secure the key.  Confirm the password and then click Next.
    • L.  Select a location and filename for your certificate.   Remember the location of your certificate that you exported.  Click Next and then click Finish to export the certificate.
  24. Return to the Access Control Services portal and click on the Certificate and keys option on the left menu.  The next step will import the recently exported certificate into the Windows Azure ACS service.
  25. In the Token Signing section click on the Add link.
  26. On the Add Token Signing Certificate or Key page fill out the form using the following guidance and then click on Save.Used forSelect Relying Party Application and then choose your applicationType – Select X.509 CertificateCertificate – Select the certificate file you exported in step 23.  Enter in your password for the exported certificate.

    Primary –  Check the Make Primary option.

This completes the steps necessary to configure Windows Azure ACS for use with SharePoint 2013.  In part 2 (coming soon) I will configure SharePoint 2013 to use Windows Azure ACS for authentication.