we’re big fans of Office 365. After
working with clients and seeing them achieve great results, we decided to
implement an enterprise suite ourselves.
We drastically reduced costs by eliminating redundant systems, achieving
an ROI of over 1000% while offering our employees better tools and reducing the
amount of time spent maintaining systems.
Earlier this year we found ourselves growing
rapidly—and our IT costs growing in kind.
costs and an increasing IT administrative burden.
At the same time we needed to upgrade certain employees to the latest
and provide all employees remote communication tools as we found ourselves
in multiple locations.
Having helped several clients migrate to Office
365, we knew it solved their business needs at a very affordable price
point. We also saw that Microsoft
continued to add key features to SharePoint Online—important to us because
SharePoint development is a major offering or our firm, necessitating a robust
internal SharePoint offering.
Over a two-week period, we migrated from
several legacy systems and services, eliminating redundant services. For example, we avoided costs from the
service that provided our public-facing website by instead using the SharePoint
internet site included in our service.
We also eliminated the hosting services for our internal SharePoint
intranet and team sites. Since our
Office 365 suite included desktop licenses of Office software (up to five
copies per employee!), we also avoided separately purchasing a lot of expensive
While the implementation was successful
overall, this and other migrations led us to note a few lessons:
up a unique user on Office 365 (firstname.lastname@example.org) to use during migration from
another system. This is best practice
because migrated documents will appear to have been authored by the user who
migrated them. Showing a generic ID
like “migration.admin” clarifies that a document was
migrated, and prevents a scenario where all content appears to have been
contributed by a single member of an organization. The “Modified By” field will always contain
the special migration User Name.
settings before migrating data. Think of
it this way: you are going to “copy” lists, libraries, web
parts, applications, etc. from one site to another. The first site may have feature activations
that are not activated on the new site.
Perhaps you have custom code solutions running that are not present on
the new Office 365 site. It is critical that you make every effort to match
the feature activations and other site settings on both sides before migrating data. If you migrate and then try to match, you’ll
generally get error messages. Best practice: deactivate custom or unneeded features on both
sites. Make sure that if Publishing is
used on the source site that you activate Publishing on the
new site before migrating. Some web
parts from a SharePoint Enterprise site will not exist on the Office 365 side,
so expect a
need for alternatives. Once the content is migrated, you can then
activate additional features on the new site as needed.
• Even after all of these precautions, be ready for some things to break. Even
as Office 365 is increasing functionality and capabilities, chances are good
you’ll lose a feature or two if you’re migrating from SharePoint 2010. For example, we lost some dashboards, but
replaced them with CloudShare. The
migration tool we used would replicate sites and their content, but we had to
reconstruct the home page of each sub site, as the tool
simply used the default “home.aspx” SharePoint page. This is not too difficult unless you have
lots of sub sites, but do it while you still have the original sites up to use
as a model.
Our enterprise package also included
other products that we have found useful, but may not have purchased
otherwise. For example, we now use
Microsoft Lync for meetings, IM, and to provide presence information in SharePoint
and Outlook; it even allows for certain conference call providers to integrate
directly with Lync. This reduces our
usage of our paid conference number service.
We also expanded our email capabilities: we now have loads of storage,
archiving, and legal hold capabilities.
Finally, Exchange and SharePoint have had better uptime than our
previous provider. All told, we added
functionality that helps our workforce be more effective inside or outside of
the office. And perhaps most
importantly, by eliminating five other substantial services, we achieved an ROI
of 1170% and a payback of only a few months.
Scenario: I recently had an issue with publishing simple changes to a Document Information Panel (DIP), and wanted to pass on what I learned about doing so to an InfoPath form or DIP. Situation: Developer machines were upgraded to Office 2010; however, end users were still on Office 2007. I made changes to a DIP originally developed in InfoPath 2007. End users complained of getting an error and the DIP would not display. I also received constant SOAP server extension errors that told me the file did not exist or had been deleted.
Issue: In InfoPath 2007, Form Options (under the Security and Trust section), the setting "Automatically determine security level" is set to Domain access by default. In InfoPath 2010, however, this setting defaults to "Restricted" access.
Considering the language used here, one would assume Domain access would be the best option. The reason is InfoPath 2010 security is based on the security model of Internet Explorer using security zones and levels. Essentially, since web-based forms have a URL, they are treated as such thus domain access is treated differently. More information on this can be found here: http://msdn.microsoft.com/en-us/library/ee526349.aspx.
Solution: If you are updating an InfoPath 2007 form or DIP, ensure the setting under Security and Trust in Form Options is set to "Restricted", as it may be set to Domain access by default.
Update: The "Restricted" Security and Trust setting only refers to DIPs. InfoPath Forms published to the server as web-based forms still automatically revert to the "Domain" setting.
One of the nice features of a cloud-based Office 365/SharePoint Online package is that you get one free public site collection, which MS calls a "vanity site". It is designed to be very simple brochure-ware, where you edit a few simple pages to provide your company contact information, describe your services, and so forth. It's not very flexible, and in fact many of the options you'd normally find in a standard SharePoint site are simply not there.
At Satory Global, we decided to migrate our Satory.com web site from a hosted SharePoint 2010 Enterprise Server environment, into the Office 365 vanity site. It turned out to be a pretty good challenge in several ways. Although our .com site is fairly static, we were using Publishing features, and highly customized branding, inherited down through several sub sites.
This article describes some of the issues that had to be overcome
First, since the "vanity site" is relatively crippled, we didn't try to use a migration tool to move the site across. Instead, we simply uploaded a new copy of all the files, including images, scripts, pages, master pages, style sheets, etc.
When we had those in place, we set the master page to our custom master, which in turn references our custom styles. The first thing we learned is that on the vanity site, sub sites do not inherit a master from the root (and there are no settings accessible to adjust that).
In fact, Site Settings doesn't even appear on the Site Actions menu -- but you can access certain settings by manually navigating to http://[site.com]/_layouts/settings.aspx.
To workaround this limitation, I made a copy of the custom Master Page and renamed it [filename]_FullPath.master to distinguish it from the original. Then the new master page was edited to include full URIs (absolute URLs) for each reference to a style sheet, a jquery library, or anything else in the master that references a URL to something elsewhere in the site.
Since the vanity site pages do not support anything except the vanity site master page, we had to edit each page in the site, in SharePoint Designer, to point it to our *FullPath.master file. After editing each default.aspx or home.aspx page, as well as any pages stored in the /Pages or /SitePages folders, our custom branding was once again "inherited" throughout the site.
Drop Down Menus are not supported
We were doing some site redesign at the same time, since the move to a new environment gave us a chance to QA the new site before switching the DNS records and going live. One of the things we wanted were some drop-down menus on the Top Navigation bar (which on our site are modified to look like Tabs).
A jQuery drop-down plugin was used to accomplish that, but even that is somewhat tricky, since in SP2010 (not just the vanity site), the Quick Launch and TopNav menus have a generic UL LI structure with no identifying class or ID below the parent DIV. That meant that we had to use a selector to add a class to the parent UL in the TopNav, so that we could bind the plugin to it -- you have to have a way to identify the specific UL tag where you want the drop down to hang from, or the plug-in would try to attach a drop down menu to every UL tag on the page.
Additional classes were added to override the customized TopNav appearance, so that the drop down would have the usual rectangular list-like behavior.
Search is not supported
SharePoint search does not crawl the vanity site, so we had to use CSS to hide the normal Search Box at the top of the page.
Overall, we think it turned out pretty well
The site you are looking at to read this blog is the site we are discussing. Using the techniques described above, and a few other lesser adjustments, we're pretty happy at having made our new site look much like the old one (even better, we hope, with the additional improvments and design changes). We hope you like it too, and that you will visit it often, to check out our blogs on Office 365 and SharePoint 2010, as well as the blog of my colleague, Neil Mackenzie, Windows Azure MVP. His blog is called Convective, and can be accessed via this site.
Although SharePoint allows - some might even say 'encourages' - the use of long, descriptive object names, I'm from the old school, and prefer brief, concise object names, preferring to use abbreviations, and Upper/lower case to minimize the use of underscores, and I avoid spaces altogether when naming objects, pages, sites, lists, or anything else in SharePoint.
When creating sites with SharePoint, particularly public-facing ones, but it applies equally to Intranet sites, SharePoint pages default to using the FILE NAME of the aspx page as the Title of the browser Tab. This is not a browser issue; because you'll see the same thing in Firefox, Chrome, Safari, or any other browser that you might be trying to use to view a SharePoint page. (IE is recommended, for obvious reasons).
Sometimes that seems to work, like when the Tab displays "Home" for your home page. But perhaps you've created a page whose subject matter is "Public Sector Consulting Services", and you've named your page 'pubSecConsSvc.aspx', or maybe just 'pubSec.aspx'. Suddenly, your browser tab just displays "pubSec", and you'd rather have it display "Satory Global - Public Sector Consulting Services" (even though the user will only see the whole string when they hover the mouse over the tab).
As always, there are a couple of ways to do this in SharePoint, and a couple of variations in different page types. Below, I'll describe what to find on the page, and what to replace it with. You will need to use SharePoint Designer 2010 to make these changes.
Open your site in SharePoint Designer
From the home page of the site you wish to modify the Title of, you can click Site Actions, Open in SharePoint Designer, and the site will open. Of course, you can also run SharePoint Designer first, and open the site from within.
Identify the Home Page of the site, usually "default.aspx" under All Files, or "Home.aspx", under /SitePages/, though you may have selected some other page as the home page. The Home Page has a little "house" icon next to it, so that you can easily identify it.
Right click on the page name in Designer, and Check Out if necessary. Right Click again, and click "Edit in Advanced Mode", because you'll be modifying a portion of the page not editable in regular Edit Page mode.
If you double clicked your page and opened it, you can always select "Check Out" and "Advanced Mode" from your ribbon menu.
Either way, once you've done that, the page code will be visible, with no yellow highlighting on the normally protected sections. By the way, select "Code" View, because you don't need to see the Split or Design Views for this, and Designer will be more responsive.
Look near the top of the page
We will be modifying the ContentPlaceHolder called "PlaceHolderPageTitle", highlighted above.
Another variation you might see is:
In the first (highlighted) example, '<SharePoint:ProjectProperty Property="Title" runat="server"/>' is the code that inserts the File Name into the browser tab. You can see that it is followed by a literal dash, " - ", and then by another Property, which in the first example is empty, but in the second example, is set for "BaseName".
Generally, it's best to remove BOTH of these properties; either one can have an undesired effect on your Tab value.
Here is what to put in there instead
As noted, the dash in the code above does render on the page. It's just literal text, which is what you can put inside the asp:Content tags to get the desired result in your Tab:
This will render just fine; the asp:Content tag can handle plain text.
Or, if you have a preference, or a policy, of keeping everything confined to server tags, you can use:
This wraps the same text in a SharePoint:EncodedLiteral tag, lists the value as the "text" property, and encodes it using HtmlEncode (or some other encoding scheme of your choice).
Save your changes
When you've finished editing the PlaceHolderPageTitle ContentPlaceHolder, be sure to save your changes, and check in the file (or Publish and Approve it, if necessary), and close the Site in Designer.
If you were working on an Intranet site, you've probably already verified your changes in the browser, but if you're working on a public site, or other site the allows Anonymous access, you can't readily check the results without Check In/Publish/Approval steps first.
Remember, you may need to do this for every sub site, and even for each page in the /SitePages or /Pages libraries, in order to get the desired result on each tab. It may be tedious on a larger site, but the result is a more professional-looking site with meaningful browser Tab Titles, and you still get to use your short, efficient file names underneath!
Our company had been operating a full SharePoint 2010 Enterprise Server instance in a hosted environment for about a year and a half. We had our public Internet site, an Intranet consisting of numerous site collections, an Extranet for various business partners to collaborate in, and some internally-used development sites.
Paying for a hosted environment like this can get expensive, so when we became a Microsoft Partner for Office 365, we decided to migrate all our SharePoint sites into that Cloud environment. Sounds simple, right? Read on, and maybe I can guide you around a few pitfalls, and at least alert you to others.
- Preserve Version History, Created and Modified By (Authorship), and Modified Dates
- Retain existing functionality and look and feel (transparency)
- Leverage the single public-facing site to host http://www.satory.com/
- Avoid URL changes as much as possible
- Preserve Security and Permissions configurations to the extent possible
There are no built-in tools in Office 365 for migrating existing sites
Several third-party companies offer similar toolsets for performing migrations, backups, and other site-maintenance functionality. Since our Intranet and Extranet sites were primarily document repositories and simple project collaboration sites, without a lot of custom code deployment or workflows, we selected MetaVis Online, from http://www.metavistech.com.
MetaVis has a full fat-client migration tool that provides very granular migration mapping tools, but unless you're moving a very very large site, or many of them, it may be hard to justify the cost. MetaVis Online, the tool we used, is cloud-based, and is operated through a simple web interface. You provide the tool with a login for each system, select some migration options, and it schedules and executes the job. You can opt for it to create and migrate sub sites, or just one site at a time, to sync content in existing sites, etc.
There are Security differences that get in the way
The Online tool we used will only preserve Authorship information if it can match the UserID on each side. Since some of our content on the old sites had been created by users who were no longer on board, we would not have their ID on the Office 365 site. In this case, the Authorship becomes the UserID that was used to do the migration, so we created a new user on both systems called "Migration Admin" [First Name + Last Name]. That way, any mismatches would not all be attributed to the person performing the migration, and it lets you clearly know that the authorship changed due to the migration.
As it turns out, that's not enough. Because the old envrionment used Active Directory, and Office 365 has its own User Admin system based on email addresses, none of the UserIDs matches, and everything ends up being attributed to "Migration Admin". (In the full version of MetaVis, there is a UserID mapping feature). We found a partial workaround for this issue: We added all of our users as Site Collection Administrators - just during the short migration period, and only to the Office 365 site, to which they did not yet have access - and that allowed name matches for items created by those individuals.
There are no warnings about mismatched Feature sets, etc.
This one caused us to delete everything and start over. We initially tried to perform the migration using the existing Feature activations on the Enterprise site, and the default Feature configurations on the Office 365 site. Wrong move. The migration tool will simply copy all the content over, creating folders, pages, etc. that are normally created by activating a Feature. However, you find that some of those migrated objects do not work, and now you can't Activate the Feature, because some of its parts already exist (many of you may have had that experience when trying to Activate Publishing where a Style Library already existed). You don't get a clear error, just the usual "Exception".
So, we deleted the sites we had already migrated, and recreated them. Then, we went to the Enterprise Server sites and began turning off Features that would either not be available in Office 365, or were not being used in the sites. We activated some features on the Office 365 sites, paring down the Activated Features list to about seven key Features on both sides, which matched exactly.
Then we ran the migration again, and this time everything that moved across worked as expected.
The online tool we used does not create Navigation or Home Pages
This is probably because you may be copying content into a different site structure, or a different site type. We spent many hours reconfiguring Top Nav and Quick Launch settings on each site and sub site, and also had to rebuild the default Home Pages, which defaulted to out of the box content. It wasn't too bad, since all the Lists and Views were there, but it does take time.
By the way, you can't take the root site of a Site Collection, and migrate it to a sub site; you have to migrate it to another root site in a new Site Collection. Nor can you probably take a sub site and turn it into a root site.
We needed to recreate SharePoint Security Groups
The online tool does not migrate Security Groups, and if you have a lot of item-level security in place, you probably need to pay particular attention to those items. You'll probably have to reconfigure them on the Office 365 side.
Since we knew we'd have to recreate SharePoint Security Groups, and that we'd have to use them in lieu of some AD groups we had used before, we carefully surveyed our Security Groups and Permissions site by site, and documented them in a spreadsheet, so that we could refer back to them when setting up the groups on the Office 365 site. That worked pretty well, because we are a fairly small organization, so there weren't hundreds or thousands of Users to deal with.
Overall, we were very happy with the final results. We had a tight time window (having already given notice to our former site hosting company, and not wanting to pay an additional month's fees there), and in spite of the false start, we were able to get the migration done over a weekend. The MetaVis Online migration tool was sufficient and very affordable.
I should mention that the public-facing site was undergoing redesign at the time of the migration, so it was uploaded and configured separately (I'm not sure that it could have been migrated via the tool, because the site types are so different). That's a topic for another blog, because fitting a full-blown SharePoint 2010 Internet site into the public-facing, brochure-ware space that is provided in Office 365, requires considerable finagling.
Best of luck with your own migration to Office 365, and if you need help, call on us!
Web Part Error: Activation of solutions with sandboxed code has been disabled. Correlation ID: 7d1d4e9e-d082-4000-ca3e-a880546398f1.
About this blog
|Welcome to Blogatory, the SharePoint Blog of Satory Global, LLC. Be sure to also read "Convective", the blog of Neil Mackenzie, Windows Azure MVP, by clicking the tab above or the link below. |