Metalogix Software Blog

A new Beta version of SharePoint Site Migration Manager (SSMM) has been released. This new Beta adds a few more new features, the most notable of them being the ability to migrate feature activations to the target SharePoint site, and the ability to copy a SharePoint site collection to a different web application on the same server.

Applying SharePoint Feature Activations in a Migration

SSMM now has the ability to apply any feature activations that exist on the source side to the target side. This is a site level copy feature, that should allow any users to activate any feature on the target side, if it is already running on the source side. If the feature definition from the source doesn't exist on the target, then SSMM will not be able to activate the features (as they wouldn't exist on the target side).

Copying a SharePoint Site Collection to a Different Web Application on the Same Server

This new feature allows users to copy site collections from one server to the same server. In order to do this type of copy, one of two possible requirements need to be met. The site collection needs to either be: copied into another web application on the same server, or it's name must be changed (if copying to the same web application).

SSMM is not able to copy a site collection from a web application, and managed path, into the same web application with the same managed path. However, if the (site collection) name is changed, then the managed path should also change, and the site collection can be copied into the same web application. If the site collection name is staying the same, then SSMM would have to copy the site collection into a different web application. If the same web application and managed path are used in the copy action, then SSMM will throw a warning, and the copy will be canceled to prevent any overwrites of the original content.

For a full list of Features and Bug fixes, please see the Builds Page.

Note that this Beta build of SSMM also requires an update of the Metalogix SharePoint Extensions Service (v.3.2.20).

Details: Download SharePoint Site Migration Manager Builds.

Download your Free Trial now!

Metalogix is pleased to announce the release of a new solution, Metalogix Migration Manager for Exchange Public Folders! The Migration Manager for Exchange Public Folders (MMEPF) will be released on Tuesday, February 23, 2010.

Below is an excerpt from the recent Press Release:

"The new product simplifies and expedites the migration of Exchange Public Folders to SharePoint by using just “one hop” to either on-premises SharePoint environments or to SharePoint Online within the Microsoft Business Productivity Online Suite (BPOS). The new product also supports the complex mapping required to assure complete preservation of data and metadata."

Read the full article...Metalogix Introduces "One-Hop" Migration for Exchange Public Folders to SharePoint or SharePoint Online.

For more information, or to download a Free Trial of the new Migration Manager for Exchange Public Folders, please visit: http://www.metalogix.net/Products/Migration-Manager-for-Exchange-Public-Folders/. 

Metalogix is pleased to announce the release of a new solution, Metalogix Migration Manager for Blogs! A preview of the new solution will be given on Wednesday (February 17, 2010) at noon (Pacific time) at the Microsoft MVP Global Summit that is running in Redmond, Washington this week.

Below is an excerpt from a recent Press Release:

"Metalogix Migration Manager for Blogs allows users to move blogs from Google Blogger, WordPress, Telligent and many other popular blogging systems into SharePoint 2010. The tool preserves content, comments and categories and features a tree-based user interface with copy-and-paste functions similar to the familiar Windows File Explorer."

Read the full article... Metalogix Announces New Solution to Migrate Blogs to SharePoint 2010 - Free to Microsoft MVPs.

For more information or to download a free trial of the new Metalogix Migration Manager for Blogs, please visit: http://www.metalogix.net/Products/Migration-Manager-for-Blogs/

Hi, my name is Matt. I’m a senior developer at Metalogix. This post gives you a preview of what we’re doing to embrace PowerShell in our applications. It’s an initiative that we’re quite excited about, and we would like to know what you think.

Custom Drives

The new Metalogix application framework (version 4.0) provides a custom PowerShell drive for accessing SharePoint via our connectors. These function as a command-line analog to adding a connection to our Explorer view, using PowerShell's custom provider mechanisms. Creating the custom drive is easy. Once you've added the Metalogix snap-ins, you simply use the new-psdrive cmdlet provided by Microsoft and specify MetalogixSharePointProvider as the psprovider like so:

new-psdrive -name <name> -root <SharePoint URL> -psprovider MetalogixSharePointProvider

Once connected, you can navigate SharePoint just like you'd navigate a file system, using familiar commands like dir and cd. You can browse your sites, lists, folders and items, all from the command shell. At this point, anyone who has worked with SharePoint in PowerShell will be wondering why they should use our provider, rather than simply accessing the SharePoint object model directly. Our connector provides two key advantages over standard OM access. Firstly, our connections are more lightweight; they use far less memory to hold handles on the same objects. Secondly, our connectors seamlessly allow connection to remote SharePoint instances, without requiring the use of PowerShell’s remote capabilities. This empowers users to work against SharePoint in PowerShell without mandating as heavy a permissions set.

Cmdlets

Navigation is useful, but my favourite thing about the custom drive is that it allows easy use of the cmdlets we've developed to go with it. After all, what good is looking around if you can’t actually do anything with what you see? To this end we’ve added a few basic cmdlets for our SharePoint actions that do things like get different SharePoint objects, create them, and copy them. There’s also a cmdlet for search. By the time we release our PowerShell integration pieces out into the wild, there will be cmdlets for just about anything you’d want to do in our context menus. Combining these cmdlets allows us to create some pretty powerful PowerShell “one-liners,” like this:

search-sharepointsite -target (get-sharepointsite http://intranet/sites/target) -includedocuments -author Matt | copy-sharepointitem -copyversions -target (get-sharepointlist http://intranet2/demo/testing PSA)

That’s pretty specific, but that command will search the SharePoint site at http://intranet/sites/target, get every document authored by anyone with Matt in his name, and copy them along with their versions to the library named PSA in the site at http://intranet2/demo/testing.

My favourite application is a script I wrote to do incremental document copying. Why do I like it so much? Because with a wee bit of trickery, Windows scheduler will run PowerShell scripts! So we can schedule this script to run nightly and use it to push document changes made in a development environment out to a production environment automatically.  And this is only one simple example of the kind of things we can do with PowerShell as our cmdlet vocabulary gets more complex.

GUI Integration

Alright, at this point you’re probably saying to yourself that that’s all well and good, but I wrote the cmdlets, the PowerShell drive stuff, and the underlying framework, so of course I can write a script like that. If an average user who is used to just pointing and clicking in our application wanted to do something like that, the learning curve for using PowerShell and our cmdlets could be a bit discouraging. Fear not, for we have anticipated that issue . To take care of it, we have provided an easy way to generate scripts. And it comes with screenshots!

Just set up your job, right click it and choose “Generate PowerShell Script.”

Up pops Notepad with a script that will perform that job.

While this script may look intimidating, a lot of the more verbose and complicated parts are caused by using the most generic approach possible inside the automatic script generation, which introduces additional complexity. If you were intending to write a script to perform the same task by hand, you could do something much simpler using the Get cmdlets or navigating to the SharePoint objects you want to work with using the custom drive. But this is meant to be a generic job script with some action-specific logic to do the work. Just give it a name and save it as a .ps1 or .ps2 file and you can run it from PowerShell.

There is still work to be done increasing our set of cmdlets, but the framework is in place. We plan to quickly expand the ways we can empower users of Metalogix products with this powerful new tool. 

Matt

Metalogix is pleased to announce the promotion of SharePoint Site Migration Manager (SSMM) v. 3.6.34 from a Beta build to a Full Release build.

This new build contains a number of new features over the previous Release build, including some of the larger features like migrating permission levels, both on their own, or as a part of a site copy, improved group copying, and improved web part coping abilities.

Two of SSMM's newest features are: Support for Data View Web Parts, and Automapping Created/Modified Metadata Information, a quick rundown on these features can be viewed here.

For a full list of Features and Bug fixes, please see the Builds Page.

Note that this Release build of SSMM also requires an update of the Metalogix SharePoint Extensions Service (v.3.2.19).

Details: Download SharePoint Site Migration Manager Builds.

Download your Free trial now!

This new Beta version of SharePoint Site Migration Manager (SSMM) adds a few new features. The two most notable features that have been added to this build are the ability to automap the Created and Modified metadata fields without the use of the Extensions Service, and added support for migrating data view web parts.

Support for Data View Web Parts

SSMM now supports the migration for data view web parts, however there are some limitations. Only data view web parts that reference lists in parent or child SharePoint sites will be migrated correctly, and in general these referenced lists must be within the scope of the migration. For example, if migrating a site that contains a data view web part, and this web part references a list with a sub site, then in order for SSMM to correctly migrate this web part, the sub-site and the referenced list must be migrated with the the main site (that contains the web part). In some cases a post migration step may be required to correctly migrate web parts. This is because in some cases a sub-site, or a sub-site's list (that is referenced in the web part) may not be fully copied when the data view web part is copied, and as a result the web part wouldn't migrate correctly. The same holds true for web part pages, and publishing pages. In these cases a post migration step of copying web parts can be done to correct the issue. To do this step, select the source site, right-click and choose Copy list element > Copy web parts.

Automapping Created/Modified Metadata Info Feature

SSMM also now has an option to automap and migrate the metadata info for the four main metadata fields (Created, Created By, Modified, and Modified By), without the use of the Metalogix Extensions Service. This is a check-box option in the list copy option dialog, and is only available when SSMM cannot detect the Extensions Service on the target server. If SSMM can detect the Extensions Service, then this option is greyed out.

When used this option writes the data from the four main metadata fields into four new fields of the same name with "(Migration)" following the field name. SSMM can then migrate these additional four metadata fields to the target. After a migration the original four metadata fields will be filled with the migration time and the migration account information, and the extra four fields will be listed separately. In order for users to see these four columns the view must be modified to include them.

This feature will work for .TXT and similar files, however, some files, such as Microsoft Word files, store this metadata in a slightly different manner, and their results may not be as reliable.

For a full list of Features and Bug fixes, please see the Builds Page.

Note that this Beta build of SSMM also requires an update of the Metalogix SharePoint Extensions Service (v.3.2.19).

Details: Download SharePoint Site Migration Manager Builds.

Download your Free trial now!

Hello, my name is Aaron and I’m a senior developer for Metalogix Software. I’m beginning a new series of blog posts from our development team. The new content will be technically focused and we hope you find it useful.

The client object model is a new feature of SharePoint 2010 which enables developers to interact with SharePoint remotely through a very nice, clean object model instead of messing around with XML and the SharePoint web services. It is designed for use in .NET applications, Silverlight applications, and for use in JavaScript running client-side in a web part. There is an excellent detailed breakdown of the client object model in Microsoft employee, Eric White’s blog post. I’ll try to summarize the key points and provide some analysis of the client object model based on my own interactions.

How does it work?

At the time of writing, you simply need to add a reference to Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll and you’re ready to go, although there are hints in the article that this may change slightly when the full product is released. Once you have the references added, you can create a “ClientContext” object and set up the actions that you want it to perform and then call “ExecuteQuery” to have it execute them. The client-side object model is reported to work entirely through a single new web service located at http://server/site/_vti_bin/client.cvs. This web service has a single method call, “ProcessQuery,” which takes in a request that tells it what to do and returns the results of the requested actions. “ExecuteQuery” is supposed to result in a single service call to this service. However, the Fiddler monitoring tool reveals this isn’t 100% accurate. For every “ExecuteQuery” call the object model makes two web service calls, the first one to a new method of the “Sites” web service called “GetUpdatedFormDigestInformation” and the second to the “ProcessQuery” method of the Client service. The client object model uses the SharePoint object model to retrieve and set data. This is demonstrated by the fact that you can use it to set the created/modified metadata of list items!

What are the selling points?

Apart from a massive increase in ease of use, the other big selling point of the client object model is that it can be faster and easier on the network than using the current web services.

Batch up anything

An issue that we have in both SSMM V3 and the NWS Adapter is that there are some actions that we would like to be able to do all at once, but must be done piece meal. This is most commonly a problem with data fetching, but it can be with writing as well. In the client object model you can batch up any number of fetching and setting operations under any number of action types and make it all happen as part of a single call. For example, with the current web service selection we have to fetch the sub lists and sub webs of a web separately. In the client object model we can fetch both as part of the same call. In fact, if we thought the network could handle it, we could fetch all the data needed to build out the entire tree view in a single call. This ability to batch up anything you want to do and do it all as part of a single call is much faster than doing it in a piece meal fashion.

Fetch Only What You Need

With web services, if you want to get a list’s title, you have to fetch all the list’s properties and all its fields, and then pull the list title from the resulting XML. With the client object model, you can fetch only the title property of the list. Every object in the client object model has a number of properties and you can fetch all of them or granularly request specific properties be fetched. This means much less data needs to be transferred over the network as you can take only what you need.

Generic Querying

Whenever you are fetching a collection of objects in the client object model you can use LINQ queries to filter which objects are returned. This can be a collection of sub webs, lists, fields, just about anything. This reduces the amount of data sent over the network because you can fetch only what you need. Does this mean we are free of CAML? No. There are dire warnings against using LINQ queries with list items. This is because the queries are run against the SharePoint object model, where as CAML queries are run at a lower level than that. So if you were to run a LINQ query every list item would have to be fetched anyway and then the LINQ query applied to it.

What is it missing?

Not much. The client object model seems to be an expansion on the functionality already provided by web services. The only place where I was able to find it lacking in my brief overview was authentication methods. Unlike web services, it does have built in support for Forms Based Authentication. However, also unlike web services, it doesn’t provide any way to include a certificate when authenticating. This means you won’t be able to use it against sites using PKI Certificate authentication.

Syntax

The new client OM uses a very generic looking syntax for setting values in SharePoint. This is an example of the call it makes to set a list description:

<Request AddExpandoFieldTypeSuffix="true" SchemaVersion="14.0.0.0" LibraryVersion="14.0.4006.1008" 
ApplicationName=".NET Library" xmlns="http://schemas.microsoft.com/sharepoint/clientquery/2009">

<Actions>
    <ObjectPath Id="13" ObjectPathId="12" /> 
    <ObjectPath Id="15" ObjectPathId="14" /> 
    <ObjectPath Id="17" ObjectPathId="16" />
    <ObjectPath Id="19" ObjectPathId="18" />
    <ObjectIdentityQuery Id="20" ObjectPathId="18" />
    <SetProperty Id="21" ObjectPathId="18" Name="Description">
    <Parameter Type="String">This is a list</Parameter> 
    </SetProperty>  
</Actions>

<ObjectPaths>
    <StaticProperty Id="12" TypeId="{3747adcd-a3c3-41b9-bfab-4a64dd2f1e0a}" Name="Current" /> 
    <Property Id="14" ParentId="12" Name="Web" /> 
    <Property Id="16" ParentId="14" Name="Lists" /> 
    <Method Id="18" ParentId="16" Name="GetByTitle">
        <Parameters>
            <Parameter Type="String">ID Test</Parameter> 
        </Parameters>
    </Method>
</ObjectPaths>
</Request>

For more information about the new client object model, refer to Microsoft employee Eric White’s blog post on the subject.

Aaron

In a recent article, Network World writer John Fontana identifies Metalogix SharePoint products as some of the most "tantalizing system tweaks."

"Metalogix's SharePoint Site Migration Manager is designed to help users who are evolving from more ad-hoc or basic deployments of SharePoint to a more enterprise structure.

The tools help users migrate between SharePoint servers or between versions of the technology. 'Since SharePoint is still a novel collaboration platform, when most companies deployed it they did it in an experimental fashion,' says Rasool Rayani, product management director at Metalogix. Rayani says now those users want to reorganize their content and structure."

Read the full article... Microsoft SharePoint add-ons offer tantalizing system tweaks

There is a new Release version of Selective Restore Manager (SRM) for SharePoint backups available. This new Release version (v. 4.0.80) contains a number of new features, including: the ability to change a site's template during a copy, the ability to preserve content types for a list or site level copy, allowing connections to MDF database backup files, and many more.

Two of the more interesting features for this build are the ability to copy content types for a list or site level copy, and the improved connection options when connecting to a content Database backup. Let's take a closer look at these:

Copy Content Type as part of a list or site level copy

Content types that exist on a source system can be copied to a target system, through a new Site Copy Options check-box, "Copy Content Types." When using this option in a site level copy, it is as easy as clicking the appropriate check-box option. While this option is fairly strait forward, there are a few things to keep in mind when doing a copy from the list level. Whenever SRM copies a list from a source to a target, it will always try to preserve the content types that exist on the list. This is done automatically, and no options are available in the "List/Library Copying Options." However, in order for the content types to be preserved, when copying a list to the target, the content types must first exist, or be available, on the target site. If the content type is not available on the target site, then the content types for the list will not be preserved.

For a short video demonstration, please click on the image below.

1. Select the source site, right-click and choose "Copy Site."
2. Select the target site, right-click and choose "Paste Site."
3. In the Site Copy Options, check the "Copy Content Types" check-box option.
4. Set any other migration options, as desired. When ready, click OK.
5. The migratin will run. When finished, any content types that exist on the source should be created on the target.

Connecting to a Database Backup.

Some improvements and features have been added for connecting to a Database (DB) backup. SRM can now connect to MDF backup files in addition to BAK files. This gives customers greater flexibility for the types of backup files they want to use with SRM.

The second main change is a new feature for connecting to a DB backup. Whenever SRM connects to a DB backup file it creates, and mounts, a temporary copy of the SQL DB. Another of SRM's new features allows you the option to choose a new target location to create and mount this temporary SQL DB. This means that you can now set the local machine, or any other location (that you can connect to locally), as the target to mount the SQL DB. The location for both the data files, and the log files, can be set manually.

Additionally, when removing a DB backup connection, you also now have the option to delete the temporary SQL DB that was mounted, or to just remove the connection (and keep the temporary SQL DB mounted). This means that you do not have to go into their system and manually remove the temporarily mounted DB, but can now have SRM do it automatically. This also means that if the temporary SQL DB will be used again at a later date, then you have the option to remove the connection, but to keep it mounted for later use.

For a short video demonstration, please click on the image below.

To edit the mounting location for the temporary SQL Database, connect to the  SharePoint DB backup file as normal, and in the "Restoration File Creation" dialog box, click the "Edit physical Location" button. This will open a new window where you can manually enter the new target location for both the data files, and the log files. Once these have been entered manually, click "OK," and then click "OK" again when you are ready to start mounting the SQL DB backup.

To remove the temporarily mounted SQL Database, remove the SharePoint DB backup connection, and click "Yes" when SRM asks you if you would like it unmounted.

For a full list of Features and Bug fixes, please see the Builds Page.

Note that this build also requires an update of the Metalogix SharePoint Extension Web Service (v. 4.0.50).

Details: Download Selective Restore Manager Pro Builds

Download your Free trial Now!

Metalogix Director of Sales - Archiving, Frank Mitchell recently helped Ferris Research with their analysis of Microsoft Exchange archiving solutions. This is an excerpt from David Ferris's blog:

Delete PSTs and Tapes Within Retention Window

When you define a retention policy, don't just impose on the archive.

• PSTs and Tape backups are still lingering around.
• They are subject to e-discovery, and retrieving information from them can be extremely expensive and disruptive--far more so than with an archiving tool.
• Tapes and PSTs need to be disposed of within the retention window.
• Don't forget third-party external material; e.g., material at Iron Mountain.
• Tapes should be used for disaster recovery. Recycle them within the retention window.

Many thanks to Metalogix's Frank Mitchell for a stimulating discussion of this topic. ... David Ferris

Download your free trial of Professional Archive Manager for Exchange today.