SharePoint Site Migration Manager Build 3.6.31 (Beta) Published (Build, SharePoint Site Migration Manager, Upgrade) Permanent link This new Beta version of SharePoint Site Migration Manager (SSMM) contains a few new features and fixes, as well as those from the previous Beta (version 3.6.30). The main new features of note for this build include: Of note among these Features is the new ability to include PKI certificates when connecting to a site or server. This feature will allow SSMM to use these client side certificates whenever it contacts the site or server using the credentials that are entered. Also of note is the ability to copy Permission Levels as a part of a normal Site copy. This feature helps remove the creation or copy of Permission Levels to the target site as a pre-migration step, and allows users to copy them at the same time as the rest of the site content. Some of the more notable bug fixes include: We have also started basic localization changes of SSMM, for Japanese, in this Beta. For a full list please see the Build Notes. Note that this build uses a newer version of the Metalogix SharePoint Extensions Service (v. 3.2.17). Details: Download SharePoint Site Migration Manager Builds. Posted by Metalogix at 11/3/2009 9:08 AM Comments (0) Michael Gannotti Interview at SPC09 With over 31,000 followers, SharePoint social media expert Michael Gannotti (@gannotti) is one of the most prolific tweeters/bloggers in the SharePoint community. During Microsoft SharePoint Conference 2009, Mike came by and did two interviews with us at the Metalogix booth. In the first interview, we talk about Metalogix SharePoint Site Migration Manager and how it makes upgrade to SharePoint 2010 a whole lot easier. Migration and upgrade to SharePoint 2010 was also the topic of the Metalogix session at SPC 2009 (presented by our CTO, Julien Sellgren and Stephen Cawood). Posted by cawood at 10/27/2009 6:55 PM Comments (0) Website Migration Manager Build 3.3.52 (Beta) Published (Build, Upgrade, Website Migration Manager) Permanent link There is a New Beta release of Website Migration Manager available for download on the Builds page. This Beta contains a number of improvements, and bug fixes as compared to the previous Release Build. The main features and improvements of note are: There has also been some improvement through over twenty bug fixes from the previous Release version of WMM (v. 3.3.35). Some of the more notable bug fixes include: Note that this build also includes an update for the Metalogix SharePoint Extensions Service (V 3.2.08) Details: Download FileShare Migration Manager Builds Posted by Metalogix at 10/14/2009 3:42 PM Comments (0) FileShare Migration Manager Build 3.3.14 (Beta) Published (Build, Upgrade, FileShare Migration Manager) Permanent link There is a new Beta version of FileShare Migration Manager available for download on the Builds page. This build includes some new features and improvements, such as: Some of the more notable Bug fixes include: Note that this build also includes an update for the Metalogix SharePoint Extensions Service (V 3.2.08) Details: Download FileShare Migration Manager Builds Posted by Metalogix at 10/14/2009 3:37 PM Comments (0) Metalogix Selective Restore Manager Pro Gets Top Marks Metalogix Selective Restore Manager (SRM) Pro was recently reviewed at SharePoint Reviews, by Mike Ferrara, and received a 5 out of 5 rating! Mike, who is the owner of Ferrara Data Consulting, a web development company in South Florida that specializes in SharePoint consulting, wrote "Selective Restore Manager (SRM) Pro enables farm admins to quite easily restore site collections, sites, libraries, lists, documents, items and any other SharePoint content you can think of without the use of a recovery farm." He even had a hard time finding anything to criticize in the product, writing "It did everything that I needed it to do, and it plugged a big hole for me when needing to restore documents quickly." The staff at Metalogix are very pleased to get such a great review, and are working hard to maintain a high quality of excellence! Read the full review of Metalogix Selective Restore Manager here. Posted by Metalogix at 10/5/2009 10:03 AM Comments (0) Search Engine Optimization for SharePoint Publishing Sites with Website Migration Manager When transitioning from an existing web content management system to Microsoft Office SharePoint Server, most organizations focus on leveraging SharePoint's rich publishing, document management, collaboration and metadata features. One area they often overlook during migration, however, is search engine optimization (SEO). Although Metalogix Website Migration Manager is primarily used to move HTML and document content, along with metadata, to MOSS publishing sites, it can also help customers to adopt SEO best practices for their entire site very quickly. SEO entails configuring site structure, navigation, page content, metadata and labels to improve search engine relevance and ranking. The goal is to make it easier for customers and partners to find you through search engines such as Bing and Google. Microsoft has created a whitepaper on SEO optimization that drills down on specific SEO tactics that can improve search engine relevance for MOSS sites. It can be found here: http://msdn.microsoft.com/en-us/library/cc721591.aspx 1. Use accurate keywords in your page <TITLE> tag Create a Site Inventory Video Using XPath to Check Your HTML Video Leverage Excel to update SEO relevant metadata Create an SEO Optimized Site Structure Clean up HTML Ensuring clean, semantically rich HTML is difficult to do retroactively but Website Migration Manager can help you achieve this result painlessly. Using our visual extraction tools to extracting HTML content involves an automatic "tidying" process that ensures your HTML is valid. All tags will be closed and formatted correctly. As a result, all content will render when it's loaded into a SharePoint page. This in itself can be a huge improvement over what you have today. Going a step further, WMM includes a number of content-processing tools that allow you to manipulate and modify HTML. You can run find and replace operations to remove redundant tags or replace formatting tags with heading tags and leverage CSS more effectively. There is support for Regex and XPath to search and modify content. If the HTML was generated from Word or Frontpage, you can leverage Website Migration Manager's Actions framework and programmatically define transformations on your content. We have samples of this in our SDK, which can act as a good starting point. Create permanent redirects Takeaway Posted by cawood at 9/29/2009 3:08 PM Comments (0) Metalogix Wins MSExchange.org Readers' Choice Award (Archiving, News) Permanent link Metalogix Professional Archive Manager for Exchange (formerly known as exchange@PAM) has been voted MSExchange.org Readers' Choice Winner in the Email Archiving category. This is the third consecutive year that Metalogix has been honored with this award. "Our Reader's Choice Awards give visitors to our site the opportunity to vote for the products they view as the very best in their respective category," said Sean Buttigieg, MSExchange.org manager. "MSExchange.org users are specialists in their field who encounter various solutions for Exchange Server at the workplace. Their vote serves as a solid peer-to-peer recommendation of the winning product." Read the Press Release here. Posted by Application at 9/28/2009 3:00 PM Comments (0) The 8 Best Practices for Email Archiving (Best Practice, Archiving) Permanent link Government organization and enterprises alike are required to preserve copies of email for future requests both internal and external. This mandate includes compliance with e-discovery laws including the Federal Rules of Civil Procedure (FRCP)and the Freedom of Information Act (FOIA). When organizations are faced with an e-discovery request, they are likely to find it expensive and time consuming to execute retrieval from backup copies. Email archiving is a simple – and cost effective – way for both public and private organizations to assure speedy and complete responses at any time. I recommend that any organization follow these eight key best practices: Review your archiving policies annually, communicate them to end users clearly, and execute them consistently. Email archiving is a journey, not a destination, but the trip doesn't have to be difficult. By Frank Mitchell Posted by Ken Savage at 9/23/2009 1:19 PM Comments (2) SharePoint Site Migration Manager Build 3.6.30 (Beta) Published (Build, MOSS 2007, SharePoint Site Migration Manager, Support, Upgrade) Permanent link This new Beta version of SharePoint Site Migration Manager (SSMM) contains a few new features as well as some bug fixes. In fact, this Beta is a bug-bash with more then twenty bug fixes. Some of the new and extended features for this build include: Some of the more notable bug fixes include: For a full list please seem the Build Notes. Note that this build uses a newer version of the Metalogix SharePoint Extensions Service (v. 3.2.16). Details: Download SharePoint Site Migration Manager Builds. Posted by Metalogix at 9/23/2009 9:49 AM Comments (0) Selective Restore Manager Pro Build 4.0.67 (Beta) Published (Build, MOSS 2007, Upgrade, Selective Restore Manager) Permanent link This build of Selective Restore Manager (SRM) Pro is the newest Beta release, since the launch announcement was made. This new Published version includes a few new useful features: Note that this build also requires an update of the Metalogix SharePoint Extension Web Service (v. 1.0.34).
The Microsoft whitepaper gives a great overview of some core SEO best practices. This post addresses how Metalogix Website Migration Manager can help implement these tactics. Here is a high-level summary of the key tactics that can help improve search relevance:
2. Use descriptive headings for pages that include relevant keywords (<H1>, <H2>, etc. tags)
3. Use descriptive text for site labels (navigation structure) that include relevant keywords
4. Set ALT and TITLE attributes for image tags
5. Simplify the site structure to avoid deep site hierarchies
6. Use valid HTML or XHTML
7. Use proper semantic HTML tags including Heading tags, List tags.
8. Use permanent redirects to inform search engines of navigation changes
Following these guidelines manually requires substantial effort and forces editors to modify content pages one at a time and rebuild site structures. With Website Migration Manager, the MOSS implementation team can tackle these activities efficiently and automate migration tasks at the same time.
Getting started – Create a site inventory and review titles and keywords
A good place to start is creating a site inventory using the website crawling engine built into Website Migration Manager. When the crawl is complete, you immediately identify which pages are lacking page titles and keywords by browsing the project datasheet
Check for Heading tags and ensure that Img tags have Alt attributes
Using Website Migration Manager's XPath toolset, you can quickly query all web pages for their heading and head tag (<HEAD>) content. You can use the following query //H1 to extract the H1 content in your project database. Repeat this process for H2, H3 etc. You can also check to see if Alt tags are set on Image tags with this query //img[@alt=""], which is a good SEO practice.
Once you have this data, you can answer an important question: Are your pages leveraging heading tags? Or are they using formatting tags to visually represent relevance? If heading tags are not being used, you can flag offending pages for more detailed analysis and amelioration. Website Migration Manager can assist in refactoring HTML to correspond to semantic standards that help search engines index content accurately. More on this below.
After you have looked at the extracted data, you can export the content to Excel and edit it there. This is particularly useful as you can circulate the spreadsheet to a larger audience so they can fill in the blanks and update inaccurate data. Although this is a straightforward task for keywords and titles, cleaning and optimizing HTML can often be easier when you use SharePoint's content editing features or Website Migration Manager's action framework. When you finish editing, you can re-import the SEO-optimized metadata into the project database and map it to SharePoint.
Define and create an optimized site structure automatically
One of the great features that Website Migration Manager offers is the ability to easily create or customize a SharePoint site structure. The best way to quickly define a site structure in SharePoint is to start with a flat list of paths in Website Migration Manager. You can automatically extract these paths from your existing site structure at crawl time, edit them manually using Excel, or pull them out of your HTML content using XPath queries. If a given site structure does not already exist in SharePoint at migration time, Website Migration Manager will create it automatically. You can specify a site description, site properties and what site template you want to use in the project database. It is important to remember that the value in this exercise is to use keyword-rich site labels and to adopt a structure that enables end users and search crawlers to find your content easily. It is also worth noting that you can implement the site structure as a standalone activity without loading any content, which is great for dev environments and testing.
Website Migration Manager tracks both the originating URL that content came from in your legacy site and the new MOSS URL. You can export this data to Excel and marry it to existing site analytic data. Once you have identified which pages had high search relevance, you can create permanent redirects and ensure that adopting a new SEO-optimized site structure doesn't affect your legacy search ranking.
A few of these points deserve a drill down and will be addressed in future posts. The takeaway is that, in addition to reducing the overall migration effort, Website Migration Manager enables organizations to quickly adopt SEO best practices when moving their content to a SharePoint hosted publishing framework.
Tuesday, November 24, 2009
SharePoint Site Migration Manager/ Website Migration Manager
Sunday, November 22, 2009
Microsoft SQL Server Reporting Services (SSRS) Installation/Configuration Guide for SharePoint Integration Mode
Friday, November 20, 2009
Querystring parameters you should not use in your SharePoint application
Today I have been working on a support case where customer experienced exceptions in sharepoint when passing in specific query string parameters which are evaluated by his web parts. The URL looked similar to this: http://servername/Pages/MyPage.aspx?ID=<number> The problem here is caused by the fact that the customer used a reserved query string parameter. When creating the SPContext object SharePoint evaluates the following query string parameters if provided: To ensure that the creation of the SPContext object does not fail your application should ensure that your query string parameters are different from those listed above.
Limitations of STSADM -o export/import related to publishing sites
STSADM -o export/import is often used to split site collections into multiple pieces when they reached a certain limit. Or to do the vice versa and consolidate multiple site collections into one larger one. Both of these actions work fine as long as the migrated content does not use the publishing feature. For site collections that make use of the publishing feature it is not supported to migrate root sites into sub sites or sub sites into root sites. The reason for this limitation is that the publishing feature stores vital information like page layouts but also various properties like information about variation, reusable content and so on in the root site of a site collection. When migrating a root site into a subsite the imported content will link to the new location of the previous root site. E.g. the page layout URLs will afterwards point to the page layouts library in the sub site and not of the root site which does not work as the publishing feature requires these items to be in the root site. So additional actions like moving the page layouts to the root site and adjusting all page layout urls would be required. Similar things would be required for variations and reusable content. On the other hand when migrating a sub site to a root site it gets even worse: in this situation important content which was stored in the root site of the site collection is no longer available as the sub site does not contain the necessary information as they haven't been exported in the first place. So after importing the subsite as new root site items based on the publishing feature will be non functional. Be aware that this limitation will also affect sites with custom features which store information outside the current site. Valid migration scenarios when using the publishing feature are the following:
(using a custom application you can specify which sub sites to export if you would like to avoid to export all of them)
Wednesday, November 11, 2009
Site Definitions versus Site Templates and deciding on the correct customization approach
Site Definitions A site definition is the core definition of what a site is in SharePoint. A site definition is installed on file system of web front ends, located at ..\12\Template\SiteTemplates. This directory is language-neutral. A site definition consists of .aspx pages and .xml files with Collaborative Application Mark-up Language (CAML). A major benefit is that the Page and List definition is read locally from the file system, not from Content Database. A site definition Page and List definition are cached at IIS process startup Customizations made to site definition are stored in content database, not on the file system. This can be performed via SharePoint Designer, or when custom site templates are saved. are developer created Localization: WSS 3.0 supports full site template localization (based on ASP.Net 2.0 via XML files and .ASPX files pulling strings from RESX files. Therefore solutions can be shipped "language packs" of resource files. "Global Template" defines commonality across site definitions; it gets called before any other template. It works by injecting common provisioning content into all new sites. ONET.XML file defines base types, galleries, mobile redirects Site Definitions and Configurations - http://msdn2.microsoft.com/en-us/library/aa978512.aspx CAML - http://msdn2.microsoft.com/en-us/library/ms462365.aspx Site Template A site template (*.stp file) is created through the user interface or through implementation of the object model. It is a package containing a set of differences and changes from a base site definition. The site template package is stored as a CAB-based file that can be downloaded or uploaded to site collections by users with the appropriate rights. As before, site templates offer a measure of portability to SharePoint Applications. It is not as performant as a pure site definition as site definitions are cached on start of IIS on the web front ends while site templates are stored and hence need to be fetched from the content database and merged with the site definition code at runtime to render the site. Also note that if you plan to transfer a site template to separate farm, that the farms have the same versions installed of SharePoint installed. (hotfixes,etc.) This is due to the dependence site templates have on the original base site definition they were created from. Deciding Between Site Definitions and Custom Site Templates See : http://msdn2.microsoft.com/en-us/library/aa979683.aspx When choosing whether to create a site template or a site definition, first consider the following issues: Are the changes you need to make simple or complex? If, for example, you need to make only minor changes in the look of certain pages and add a few fields in particular lists, you should create a custom site template. However, if you need to create new content types, add new Web Part definitions, and significantly restructure sites, you should create a custom site definition. Can you deploy changes to the front-end Web server? If you do not have access to the file system of the computers running Windows SharePoint Services, you have no choice but to create a custom site template. Custom site definitions hold the following advantages over custom templates: Data is stored directly on the Web servers, so performance is typically better. A higher level of list customization is possible through direct editing of a Schema.xml file. Certain kinds of customization to sites or lists require use of site definitions, such as introducing new file types, defining view styles, or modifying the Edit menu. Site definition disadvantages include the following: Customization of site definition requires more effort than creating custom templates. Editing a site definition after it has been deployed is difficult. Doing anything other than adding code can break existing sites. Users cannot apply a SharePoint theme through a site definition. Users cannot create two lists of the same type with different default content. Customizing site definitions requires access to the file system of the front-end Web server. Custom templates hold the following advantages over customization of site definitions: Custom templates are easy to create. Almost anything that can be done in the user interface can be preserved in the template. Custom templates can be modified without affecting existing sites that have been created from the templates. Custom templates are easy to deploy. Custom template disadvantages include the following: Custom templates are not created in a development environment. Custom templates are less efficient in large-scale environments. If the site definition on which the custom template is based does not exist on the front-end server or servers, the custom template does not work.
