In the scenario from my last post, we use the primary My Site for intranet users; then we have secondary My Site for extranet users or customers. Depending on your policies you might want to lock out those two groups of My Sites from being accessed by two sets of users groups as new My Sites get provisioned. After all, you don’t want to run around and change security permissions on the newly created site collection every time.

Here is what’s involved in setting up Read Access security on newly provisioned My Sites.

1. Navigate to the Central Administration -> Manage Service Applications
2. Select User Profile Service Application proxy of your interest and pick Manage from the ribbon for that service application proxy. Here the service application you will pick will be the one you want to manage security for (in my case the one hosting intranet or extranet My Sites)
3. From the My Site Settings group click on Set Up My Sites
4. Scroll down to the bottom to the Read Permission Level section and enter the security group that will have access to the relevant My Site group.

Here, the user who has created the My Site, will already have access to the site, so here you just specify the group of users with Read Access to the site. You might want to remove everyone so that the site is private and available to its owner. In which case, you have created a bit of a private drop box for the users since all of the other social features will no longer be relevant.

Enjoy!

Every time companies choose to get on board with SharePoint or migrate to a new version of, content migration is something not too many people are looking forward to. There is a lot of pain points and exceptions.
Automatic migration versus manual?
If you choose automatic, you have to think about new content types, metadata, versions, permissions, create by fields etc.
In many cases by attempting automatic migration of content, you might run into more exceptions than rules.
In this post I would like to explore manual content migration with the tool from Sharegate so you can see that manual doesn’t mean – completely manual.

I got the trial of Sharegate from here.
One thing you’ll notice right away is that Sharegate is agent-less, so you don’t need to install anything on servers you’re going to work with, just download it and it’s ready. This is something I really like about tools.
As for the UI of the tool, it’s straightforward, you got 3 options:

1. Upload files to SP (fileshare, desktop etc)
2. Move and Copy files between various versions of SP
3. Copy list data between various version of SP

Another cool thing is that you can connect to the site with the URL and pretty much any authentication method: Forms, Claims, Windows, etc … so you can migrate Office 365 data, which is pretty cool if you’re moving to the cloud or hybrid environment.

One feature that I think is the best part of the product is the ability to map properties of the source and destination lists/libraries. So if your source library has 5 metadata columns and destination has some other 5 columns, you can map which source property value will be recorded in the respective destination property column. This is really useful when consolidating lists and libraries.

One thing I miss is the ability to double click on the source file and preview it just in case I have multiple files with the same name.

However, there are helpful links to take you to the source or destination library. I think this is one of the things I like about this tool, very intuitive, well though out for what it does.

Another important feature I think is the ability to copy permissions and version history if required and make it optional if not required. In fact, you can define you own copy template so if you have something like 50 project sites following the same idea, you can apply your custom copy template and use it.

And one last thing I want to mention is dealing with illegal character replacement. As you all know, illegal characters can make it really difficult to migrate your content. Sharegate replaces all of those with a dash; in fact you can map your own replacements:

Hope you found this review useful, if so, check out the trial on Sharegate’s site and if the tool meets your needs.

Enjoy!

With SharePoint 2010 My Site functionality is managed by User Profile Service Application, and as any other SharePoint service application, you can have web applications subscribe to one or more service applications.
In our scenario, with 2 web applications (one for extranet, another for intranet site) you can dedicate separate My Site functionality for both.

Let’s see what’s involved:

1. Ensure you have 2 web applications created with desired authentication schema etc.

2. Navigate to Central Administration -> Create site collections
Here we’ll create a new site collection which will be dedicated to hosting My Sites, aka My Site Host; but first we need to create a new managed path.
3. Click Define Managed Path as shown below.

4. Ensure you have selected the web application used for your extranet (or intranet if you’re doing this for intranet)
5. Define paths as shown below, ensure the name and the type.

6. Now, we’ll create a site collection which will host the My Site Host. Navigate to Central Administration -> Create site collections.
7. Select the correct web application (extranet or intranet)
8. From the Web Site Address, pick the [extranet or intranet web application URL] / my managed path. Ex. http://extranet.contoso.com/my
9. From the Template Selection, pick Enterprise -> My Site Host and create the site collection.

Next, we’ll create a new User Profile Service Application proxy, so that only the extranet web application can use it.

1. Navigate to Central Administration -> Managed service applications
2. From the ribbon click New -> User Profile Service Application
3. Set the necessary parameters to create the new User Profile Service Application proxy; if you have existing user profile service application ensure you pick separate: Profile Database, Synchronization Database, Social Tagging Database.
4. For the My Site Host, specify the URL of the site created in step 9 above, which is likely to be [extranet or intranet web application URL] / my
5. For the My Site Managed Path specify the my/personal as we defined in step 5.
13. Provision the service application for the extranet and repeat steps 2-12 for the intranet web application unless you already have the User Profile Service Application created for it.

Now that both service applications have been created, you need to ensure that only one of the web applications uses its respective User Profile Service Application and not both.

1. Navigate to Central Administration -> Managed web applications
2. Select extranet web application and click Service Connections from the ribbon as shown below

3. Ensure that only specific User Profile Service Application you have created for extranet is selected along with other service applications.

4. Repeat steps 1-3 for the intranet web application.

That’s it, your baseline is set, now only users accessing the correct web application will be able to create My Sites for this web application. Next up, how do you restrict which users can see which My Site.

Enjoy!

Beware of out-of-the-box forms
You know all of those handy DispForm.aspx and EditForm.aspx, well those may be really great for a collaboration site, but there is really no place for them in a public site scenario, at least for general audience to see. First of all, those forms expose fully or partially the collaboration functionality which users have no access to (alerts, workflows stc) … secondly, they just don’t inherit your beautiful masterpage and look just plain. Lock all of those down; one of the recommended approaches is to enable ViewFormPagesLockdown feature on the site collection, which should be enabled by default for Publishing Sites. This will ensure, View All Site Content, and other internal pages are locked down too.
Read more on Lockdown Mode in SharePoint 2010

Careful with out-of-the-box modal dialogs, they bite
Modals look ok for a collaboration site, but for public site they are not something you should actively rely on. First, they make your site look dated; secondly, they load a lot of JavaScript making your site slow; finally, have you seen how modal dialogs render on a mobile device? Try zooming into the dialog on a touch phone . If you need your users to enter data, just create a web part for it, it’ll be worth it.

Test customizations as an anonymous user
If your site has customizations, such as web parts or application pages, make sure all of those work under the anonymous user. In the best case scenario, your web part won’t render on the page. In not so lucky scenario, you will get an Access Denied on entire page or just plain old equivalent of SharePoint 500 Error. If you have a suspicion that a web part is crashing your page, use an old trick – append the URL of the page with ?contents=1 … as in default.aspx?contents=1 and you will see a web part maintenance page where you can disable individual web parts and then go back to the page and add the web part again with a proper configuration.

Test the content as an anonymous user
Same as above, but this time related to content. Especially if you’re using publishing workflows and your page is in checked out or pending approval state, you will not see latest changes when accessing the site under anonymous user. In some cases, if you’re using a sophisticated automated deployment as described in chapter one of my book here you may forget to publish and approve pages resulting in entire site to have blank pages. Obviously, again, using my wonderful book example, you can just bulk publish all of those pages in a matter of minutes.

Weather, stock, twitter, and other JavaScript web parts – those can be trouble
If you’re using Weather, Twitter, some kind of real time or pseudo-real time stock web part ensure that those run asynchronously. If your weather web part is pulling multiple JavaScript files from a weather provider loaded with ads and those take time to load – your entire page can fail to load until that web part has loaded its resources. If you run those web parts in asynchronous mode, they load when they’re ready but the user is still can view the site. This also applies if you’re hosting ads from an ad provider.

Check for JavaScript errors on page
If you’re using legacy JavaScript modules; something that was created 3 years ago and you’re not referencing the latest JS libraries, you might not only lose cross-browser compatibility, but also cause occasional JavaScript errors on page. Keep in mind that depending on where your JavaScript error has occurred, the rest of JS scripts may fail to load making your page look ok, but be partially or completely dysfunctional.

Use analytics, in-and-out-of-the-box
One of the most important measures for any public site, is it’s usage. This is really the only way for you to know your customer reach. So make sure you use analytics, both out-of-the-box SharePoint, ISV analytics tools, and classic things such as Google Analytics.

That’s about it. Obviously, the list is not a final list, public site is a journey with continuous improvement opportunities, so keep up with it.

Enjoy!

Keep the branding fresh
This applies to new sites and existing designs to be ported over to SharePoint as a new platform. The branding of your site will represent what your company is all about online. So, freshen up your site with few new ideas to keep it up to date.

Be mobile friendly
Remember about mobile devices, and not just phones, tablets too, and not just that one tablet. If you’re going to be supporting mobile devices, make sure you support at least few current models. Most of the new mobile devices have browsers capable of running HTML5, and if they don’t they will very soon; so this is not a lot of work.
Use a masterpage which is HTML5 compatible, like this one here: http://kyleschaeffer.com/sharepoint/v5-responsive-html5-master-page/. It’ll render the masterpage differently based on the screen resolution etc.

Really think about your site Information Architecture
Now I know that you’re probably yawning there … who needs information architecture, right? And I’m sure for a large corporate site you’re doing all the due diligence to get it right, right? For small, simple sites, at least decide what main sections are you going to have on your site: About Us, Clients, Products?
The reason why you want to think about IA, is so that you can decide how each of those sections are going to look like and what content will go where. In a future, if you need to add a new section, you can re-use one of the existing ones as a template. Also, your navigation is going to be more straightforward. I’ve seen some sites where all the pages sit on a root site and there is over 50 of them; now how do you expect anyone to navigate such a flat structure?

Multilingual requirements? Think about the implementation now
Again, this is not something that will come up right away for everyone … but if you think you might have a requirement to support multiple languages on your site in a near future, think about the implementation and design your site with those requirements in mind. You might want to use SharePoint variations feature or create a separate site collections for each language. Whatever the approach, knowing it early will reduce the amount of rework once the implementation starts.

WIKIs are great for SharePoint Foundation sites
If your site is built on SharePoint Foundation, try designing it around the WIKI infrastructure. By having your main site areas as WIKI libraries you can allow your content authors to create new pages using SharePoint UI. You can also roll up those pages which translates in easier content authoring experience without having to use tools like SharePoint Designer just to create pages.

Don’t hardcode, use Content Query, Reusable Content
Content Editor Web Part is a great tool, but if you have a phone number or a link hardcoded in it on 5 different pages, you will really hate yourself when it comes to updating it.
Instead, use a reusable content list, available in Publishing site infrastructure, which allows you to reference a reusable piece of content from a single source. Same goes for roll ups. If you have news articles and such, or even company products as pages, use roll-ups rather than hardcoding links on pages.

Add some content before showing it off internally
Lorem ipsum might be realistic way of showing how the content will look like on your site, but really … just enter some real content at least for main areas of the site so that people can visualize what the site and all the sections are all about.

Are you gonna use that search or should I “return it”?
Don’t forget that search is available in SharePoint Foundation and Server versions. If you’re not using it, disable the feature so that search pages are not parsed by search engines and you end up exposing a part of the site that is not branded nor functional, ask me how I know.

Now that you mention, what about those search engines? SEO?
Yes, SharePoint 2010 needs some work when it comes to SEO. There is no way I can summarize it all in this paragraph, so I’ll give you this really helpful link. There is quite a lot on the subject.

I think this is good for starters, stay tuned for the part 2 (now posted)

You can thank me later or you can check out my SharePoint 2010 Branding book and learn more!