Sticking to the SharePoint track this morning: HMS01, HMS06, and HMS03. After that may browse other sessions.
Sticking to the SharePoint track this morning: HMS01, HMS06, and HMS03. After that may browse other sessions.
The purpose of this solution is to help resolve a longstanding issue in SharePoint – Who owns a given site? Let’s start with defining who an ‘Owner’ is. While SharePoint has the concept of Site collection administrators (users with highly elevated permissions) it has no concept of who has responsibility for the content or upkeep of an individual site. In some cases they may be one and the same, but in many cases they are different people and with different levels of permissions on the site. Sites invariably have many users with Full Control permissions – but who is the single point-of-contact out of those people? There is the concept of the Site Author/Creator – but that is not exposed anywhere in the GUI – and that value is unalterable. Over time it may not represent the person responsible for the site they created.
This solution introduces the concept of a Site Owner. The Owner would be the primary point of contact for a site – and their name would be prominently displayed on each page of the site for easy identification. An owner can be identified at time of site-provisioning, in advance or through analysis of site content and permissions. Administrators can manage and assign site owners though an easy to use interface as well as quickly identify sites with missing owners and stale or inactive owners that need updating. Administrators can define if the owner is an individual or a SharePoint Group.
The product will run in Evaluation Mode for 15 days after it is first installed. During the evaluation only the first 5 sites in any web application will be scanned.
You can also buy a license and activate the full version of the product. The solution is licensed per-farm (not per user or front-end like a lot of other solutions).
Original Article Below
If you’re like us you have struggled with this at one point or another: Who ‘owns’ a SharePoint site. We define the owner as the main business or technical contact for the site – the user responsible for the overall content, permissions, and management of the site. This is another area where SharePoint is lacking – sure there is an ‘Owners’ permission group – but that could have many users in it. It really does not identify the single point-of-contact we want to manage. When we set out to design our new templates one requirement was that we collect and display the site owner in the footer of every page so visitors had a way to identify and contact the site owner without a lot of difficulty or calling the helpdesk to inquire.
Our Site Owner control is deployed at the site collection level and is built-in to our site definition (you can also feature-staple it into existing site templates). Code in the master page renders the footer with the Site Owner stored in a property-bag:
When our users provision a new site, they are prompted to specify a Site Owner. The site cannot be provisioned without making a choice here:
Site Administrators can easily update this property at a later time via the Site Settings page:
Now this is all nice and good – users can identify the site owners and we reduced calls to our helpdesk and SharePoint support teams. But here is the cool bit. With a little PowerShell, we can instantly produce a report of all of the site owners (along with their site data) and marry that back to Active Directory to see if any of the users are disabled or deleted. This way we can make sure the Site Owner values are correctly populated and active users are managing these sites. Also great for sending out bulk-emails to the Site Owners when maintenance is required or changes are being deployed into their sites:
So there is our take on displaying and managing SharePoint Site Owners. Hope you found it interesting. Be sure to look for my tweets and blog updates from the SharePoint Connections Conference starting March 26th.
Ok I know what you’re thinking, SharePoint 2010 already has web parts that can talk to Exchange and render your inbox, calendar, etc. right on a page. Why change them? Because, for the most part, we found that trying to shoehorn OWA functionality into a web part is not what our users are looking for. We have rich-clients (Outlook) and a good remote experience (OWA) so why try to shove all that onto a SharePoint page (see: http://en.wikipedia.org/wiki/Turducken). We also ran into usability issues: They require integrated authentication to work properly for starters (which is an issue for us with external access secured by UAG forms authentication) and the branding does not work well with our designs. I am debating the wisdom of why you would want to have your inbox or calendar in a web part anyway – it’s not very functional. On the other hand, rolling up your inbox, calendar, and tasks data into a web part is appealing – and allowed us to demonstrate how to integrate other systems into our SharePoint Intranet.
This web part began as an exercise on how to 1: Integrate external systems into SharePoint. 2: Demonstrate how to present that data. And 3: Serve as a test-bed for future web parts using features like Ajax (which we used to develop the SalesForce Chatter web part, described in an earlier post). Our criteria for the web part was simple: rollup data from a user’s Exchange mailbox and present total number of unread messages, next scheduled meeting/event, and top 3 open tasks.
Above: The My Outlook web part.
The web part was surprising simple to build – thanks to Exchange Web Services (http://msdn.microsoft.com/en-us/library/bb204119). The only hiccup we had with the design was authentication. EWS can use the default credentials of the user – but the double-hop condition from the web server to Exchange will render that option useless. So we created an account that has read-only permissions on user mailboxes so the web part can gather the information on the user’s behalf. You can also use Kerberos delegation with EWS if you have SharePoint setup to use it.
Each of the items is also a hyperlink to the respective page on OWA – so you can access your inbox, calendar, and tasks – but without trying to fit it into your page layouts.
We have more plans for EWS too – including a free/busy timeline in a user’s My Site profile – so colleagues can easily check each other’s availability.
Keep checking back – greater things to come. Also – be sure to look for my tweets and blog updates from the SharePoint Connections Conference in March.
So we just finished the second phase of our SalesForce Chatter integration efforts – the displaying of feeds and basic wall-functionality: Posts, Comments, Groups, Tags, and Likes.
Here’s what it looks like:
I described the basic workings of the web part in an earlier article (https://marcrdavis.wordpress.com/2012/02/11/salesforce-chatter-integration-to-sharepoint/) so please check that out for the details. I think it worked out very well. We added the ability to cross-post to your SharePoint profile when updating Chatter, nice. We also added properties to control the number of feed items returned, the cache and refresh timeouts, and options to produce debugging information per-user so we can trace issues in production.
Users who have authorized our intranet on their Chatter profile get the full experience above – they can post, like (or unlike), and comment on items. If they have not done the authorization step yet (or it was revoked), then users will get a read-only view of the All Company feed (which is done by adding a SalesForce API-enabled account in the web part configuration). Read-Only users are invited to authorize the app so they can get the full experience:
Clicking the link starts the authorization process:
The biggest challenge we had with the design was the Chatter API rate-limit of 200 requests per user, per application, per hour. We had to get creative with caching so we would not run over the limit – especially for the read-only view.
The goal here was not to reproduce Chatter or all of the Chatter features – but rather bring the feed data and the basic social experience into our SharePoint Intranet. Links, hashtags, and attachments are redirected to a new browser window that opens to the full Chatter web application. SalesForce has been working on a version of this web part for some time – but it is still in beta and not widely available. The version we tested also had a requirement of SSL on the SharePoint front-end servers. Since we offload SSL on our load-balancers, we could not use their web part properly. Ours does use SSL to talk to SalesForce (so the feed is secure) but we don’t need to have SSL on the web applications. Our web part is also not encumbered by the SalesForce branding – so it fits in perfectly.
The next phase will continue to integrate the platforms further, with indexing Chatter so it can be returned in SharePoint search results. We may also look to embed the wall-experience in the user’s profile page.
That’s it for now – look for more on this soon. Be sure to look for my tweets and blog updates from the SharePoint Connections Conference in March. Take care.
Hi everyone – sorry it’s been awhile between posts but got really busy at the end of the year. This article continues my series on SunGard’s corporate Intranet and the custom development we’ve done. As we were designing the branding we had some challenges around where to put some of the native controls and ribbon elements – especially two in particular: ‘Tags and Notes’, and ‘Like’. Since we effectively hid the ‘Browse’ tab, those default ribbon icons were MIA – but we didn’t want to lose that functionality. Another tab in the ribbon seemed the most logical place, and would serve as way to integrate other social aspects into SharePoint.
Being new to working with the SharePoint Ribbon, I looked on the net for examples – and found a great one on CodePlex: http://socialsharepoint.codeplex.com/ . This project helped me create the new ‘Share’ tab on our intranet and relocate the ‘Tags and Notes’ and ‘Like’ buttons. The tab also contains other sharing options, like ‘Email’, ‘RSS’, and ‘SalesForce Chatter’.
Above: The Share tab open on the ribbon.
When SunGard standardized on Chatter as their social platform, the focus became integrating Chatter into SharePoint as seamlessly as possible. We’ve approached this process in stages. The first stage was basic integration – common authentication, status updates, and shaing pages, documents, and list items. The first phase was achieved with the Share on Chatter feature in the ribbon, and a custom web part for posting status updates (detailed later in this post).
Above: Clicking on the Chatter ribbon icon opens a modal window with the selected page, item, or document as an embedded link. Users can add comments and share the item on Chatter.
The Ribbon enhancement and the web part use OAuth and the Chatter REST APIs to communicate with SalesForce. The user’s token and secrets are stored in hidden fields within their profile. Once they authorize the KnowHow Application on Chatter once, they can use any of the Chatter integration features we design.
Users can also post status updates simultaneously to both SharePoint and Chatter by means of our Status Update Web Part:
This web part is placed in everyone’s Sidebar (see: https://marcrdavis.wordpress.com/2011/09/27/persistent-personalized-content-in-sharepoint/ for details on the Sidebar) making it quick and easy to post updates. The user’s posts are sent to their SharePoint profile as well as posted on their Chatter feed.
The second stage, which is underway now, involves bringing the many different feeds in Chatter directly into SharePoint. Doing this has proved challenging, since only this weekend has the Chatter v24 API been rolled out in our Org. Our Feed web part will leverage the above common authentication and will allow site owners to place feeds directly on their sites. The web part uses the REST API to pull down feed data as a JSON array (http://json.codeplex.com/) and then parses that data into feed-items and their components. Then, with some CSS and markup, we format that data into a wall view. Properties in the web part control what feed is shown (personal, company, or group) and options for supplying default credentials for Chatter, which can be used to authenticate users that do not have a Chatter profile or have not authorized the site on their profile yet. In that mode, all feeds are read-only. The web part also leverages Ajax to provide dynamic updating of the feeds without the need to repost the entire page
Our Status Update web part will then get an overhaul – adding the user’s personal feed view right in their Sidebar.
I personally would have loved to see true threaded discussions, micro-blogging, and a wall-like interface in SharePoint natively (maybe v15) – would have saved me a lot of work. But we’ve been able to do some really cool things with these two platforms and while getting them to place nice is a challenge, our end users really enjoy the experience and this helps us drive more traffic to SharePoint now that they can seamlessly collaborate on our external social platform.
Up next – our take on Exchange and Outlook integration with SharePoint.