Modeling, Deploying and Committing Deployer Project 2

Modeling a SharePoint target does not actually modify your server. All changes are made in your Tzunami Deployer project and are only applied to the target SharePoint when you commit them. For more information about committing, see Committing the Migration on page 4-84.

You can also rename an item by selecting it and pressing F2. SharePoint imposes some character and length limitations on item names. For more information, seeFolder and File Naming Considerations on page I or refer to your SharePoint documentation. Tzunami Deployer may rename folders or documents by replacing invalid characters with an underscore (_).

These procedures are similar to the procedures used in the native SharePoint environment. Any SharePoint item can be deleted, except for virtual servers and some built-in lists.

When you create a site collection, the Owner field is enabled (since only site collections have owners) and the Use unique permissions checkbox is disabled (since site collections always have unique permissions – they cannot inherit permissions from their parent, for they do not have a parent). When you create a sub-site, the opposite is true.

For a site collection, enter the owner account.

For sub-sites, select whether the site should use unique permissions. If you do not select Use unique permissions, the site inherits the permissions of its parent site.

You can select Display list on the Quick Launch for quick launch display. You can also select Specify relative URL, and specify the URL of the list. This is not a SharePoint option.

The Properties window can remain open while you work in the Project window. It reflects the properties of the currently selected item.

Several items can be simultaneously edited using the Properties window. For more information about the Properties window, see Viewing Item Properties on page 4-56.

You can leave the Replace field empty in order to remove the searched value from all names.

The Select Problematic Items is very useful if you have just deployed content but have yet to commit it, and would like to prevent illegal naming, blocked extensions and long URLs in SharePoint. For example, replacing “Business Intelligence” with “BI” is a good solution for handling long URLs.

While the cursor hovers over a property set, a hint appears displaying the number of containers that are using the property set.

 Figure 28: Metadata Editor Window

2. If you right-click a property set in the left half of the screen and select Show usage, the File Property set window appears, displaying the containers that use the selected property set.

Figure 29: File Property Set Window

3. Select an item and click Go To. Tzunami Deployer displays the selected item in the Project window.

Creating Property Sets

New property sets can be created to define the target SharePoint metadata.

To create a property set:

1. In the Metadata Editor window (Figure 28), right-click a property set (or an empty area in the properties list on the right) and select New > Document Library Property Set or New > Picture Library Property Set. A new property set is added in rename mode.
2. Type a logical name for the property set and presses Enter.

You can define new properties for this property set. For more information, see Creating and Editing Properties on page 4-43.

Creating and Editing Properties

You can create a new property or edit the existing properties for the property set.

To create a property:

1. In the Metadata Editor window (Figure 28), right-click a property set.

2. Select New > Property. The Add Property window appears.

Figure 30: Add Property Window

3. Fill in the fields according to the information in the following table and click OK.

The property is added as a new column in the list using this property set.

Table 7: Add Property Window Fields

To edit a property:

1. In the Metadata Editor window (Figure 28), right-click a custom property set.
2. Select Edit Property. The Edit Property window appears.

Figure 31: Edit Property Window

Assigning Property Sets

Property sets have underlying types that must match the list to which you assign them, so that a document library property set can only be assigned to a document library and not to a different library (For e.g. an image library) or to a different type of list. A property set cannot be used on more than one list or library. This section is relevant to property sets that are not in use (new or duplicated).

To assign a property set to a list:

1. Drag and drop a property set from the Metadata Editor onto a library or list in the Project window.

Or Right-click the property set and select ‘Assign To...’. The Target Items window appears.

Figure 32: Target Item Window

2. Select a target list to which to assign this property set and click OK.

A confirmation window appears indicating which property set will be assigned to which list.

3. Click Yes.

The Assign Property Set window appears, displaying property mapping information.

Figure 33: Assign Property Set Window – Property Mapping

4. Select a source property (top left) and a corresponding target property set (top right) and click Map. Repeat this step for each property you want to map. For more information about mapping properties, see Mapping Properties on page 4-67.

5. Click Next. The Assign Property Set window displays value mapping information based on the property mapping performed in the previous set.

Figure 34: Assign Property Set Window – Value Mapping

6. Select a source property value (top left) and a corresponding target value (top right) and click Map. Repeat this step for each property value you want to map. For more information about mapping property values, see Mapping Property Values on page 4-72. Check Add all unmapped values as legal target property valuesfor adding unmapped value to target. Similarly Check Remove unmapped target values for removing the unmapped target values.

7. Click Next.

The property set is assigned. Since modifying the property set modifies the columns of the target list and pencil overlay appears on the target location icon (for example  ).

Viewing Security Information

Security information is part of the content loaded into Tzunami Deployer projects. Several views and reports are available to assist you during the migration process.

View Permissions

Viewing permissions enables you see an item’s users and groups (on the top pane) and the security permissions assigned to each user/group (on the bottom pane).

To view permissions:

• Right-click an item and select Security > View Permissions.

The View Permissions window is displayed.

Figure 35: View Permissions Window

Edit Roles

Editing roles allows you to add, remove, or edit roles and assign specific permissions to each role. Roles are used during the migration of security settings.

To edit roles:

• Right-click an item and select Security > Edit Roles.

The Edit Roles window is displayed.

Figure 36: Edit Source Roles Permissions window

View Users Roles

View User Roles displays users roles report for each item, the security entities that have permissions on the item and their matching role.

To view the Users Roles report:

• Right-click an item and select Security > View Users Roles.

The Users Roles report is displayed.

Figure 37: Users to Roles Report

View Users Permissions

View Users Permissions displays users permissions report, for each item, the security entities and their permissions.

To view the Users Permissions report:

• Right-click an item and select Security > View Users Permissions.

The Users Permissions report is displayed.

Figure 38: Users to Permissions Report

Import/Export Role Definitions

Since roles can be modified, it is often useful to have the ability to export and import the roles definitions to a file. The roles can then be imported for use in a different project.

To Import/Export role definitions:

• Right-click an item and select Security > Import/Export role definitions.

The Import/Export Role Definitions window is displayed.

Figure 39: Import/Export Role Definitions Window

Modeling SharePoint Security and Permissions

SharePoint 2007, SharePoint 2010, SharePoint 2013 and Office 365 Security

Each site collection in SharePoint 2007, SharePoint 2010, SharePoint 2013 and Office 365 has its own list of users and groups. Once you grant certain user permissions on content or sub content of the site collection, the user is added to the site user list. Also, new groups that are created are added as site collection groups.

In SharePoint 2007, SharePoint 2010, SharePoint 2013 and Office 365 content can be secured at all hierarchy levels: site, list, library, folder, or item. Each user is granted permission for the specific content, either directly or by being a member of a site group which has permissions for that content.

Once you create sub content, the default security settings to this sub-content are inherited from the parent content. Using the SharePoint user interface, you can change these default settings and assign unique permissions to the sub-content.

SharePoint 2007, SharePoint 2010, SharePoint 2013 and Office 365 have used the concept of permission-levels, which are permission sets. Each user or group can be assigned with one or more permission-levels. Permission-levels are managed in sites and can be inherited from a parent site.

SharePoint 2003 Security

In SharePoint 2003, site group is used as a role. This means that if you wish to grant a user certain permissions, you add that user as a member of a site group that has those permissions. Each site that breaks inheritance has its own set of groups.

In SharePoint 2003, content can be secured only at the site, list, or library level. A user could be granted site permissions only by being a member of one of the site groups. Also, a user can get explicit permissions on a list or library.

Tzunami Deployer enables you to perform the following security and permissions customizations:

• Create groups
• Assign permissions to users
• Modify or delete groups
• Modify permissions
• Edit Permission Levels (MOSS only)
• View the Users Permissions report
• Import/Export users

Creating Groups

In order to assign permissions to an Active Directory user or group, you must first add the user or group to the site, either directly or as part of a SharePoint group.

To create a group:

1. Right-click a SharePoint site and select Security > Edit Users & Groups. The Manage Security window appears, listing all SharePoint groups ( ) and all Site Collection users ( ).

Figure 40: Manage Security Window

2. Click Create and select Group.

The Create Group window appears.

Figure 41: Create Group Window

3. Enter a name and description for the group and select a user to be the group owner.

4. Add members to your group and click OK.

The new group is added to the Manage Security window.

Assigning Permissions to Users and Groups

In order to assign user permissions, you must add users to a group or Cross-site group.

To assign user and group permissions:

1. Right-click a SharePoint item and select Security > Edit Permissions. The <Item Name> Permissions window appears.

Figure 42: <Item Name> Permissions Window

2. Click Add. The Users / Groups window appears displaying all the available users and groups.

Figure 43: Add User Window

3. Select the relevant users and/or groups and click OK. The selected users/groups appear in the <Item Name> Permissions window (Figure 42).

4. Select a user/group and assign the various permission / permission-levels in the Permissions area.

5. Click OK. The user/group permissions are assigned.

Modifying Groups

To modify a group:

1. Right-click a SharePoint site and select Security > Edit Users & Groups. The Manage Security window appears (Figure 40).
2. Select the group to be modified and click Update. The Update Group window appears (Figure 41).
3. Modify the information as necessary and click OK. The groups are modified.

Modifying Permission Levels

This option is available only for MOSS/WSS3.0, SPS2010/SPF2010, SPS2013/SPF2013 and Office 365.

You can modify any of the permission levels, except for Full Control and Limited Access. The permissions are inter-dependent. Selecting certain permissions might select other permissions that are required in permission levels.

To modify a permission level:

1. Right-click a SharePoint site and select Security > Edit Permission Levels. The Permissions Levels window appears.

Figure 44: Permissions Levels Window

2. Select a permission level and select which permissions to assign to the permission level.

3. Click OK.

Importing and Exporting Users

Tzunami Deployer enables you to export or import Active Directory users and groups to an XML file. For organizations with a large Active Directory, you can connect and read the entire Active Directory domain users and groups once and then export it. Future projects can then import the XML file instead of rereading the Active Directory domain.

To export users:

1. Right-click an item and select Security > Import/Export users. The Import/Export Users window appears.

 Figure 45: Import/Export Users Window

2. Select Export users to XML file and click Browse…

3. In the File Name list, type or select a name for the file.

4. Click Export. The users are exported to the XML file.

You can manually create your own users based XML file or edit existing ones, and add other users (using Excel or any other tool that generates XML files) and import it.

To import users:

1. Right-click an item and select Security > Import/Export users. The Import/Export Users window appears.
2. Select Import users from XML file and Click Browse…
3. Select the XML file containing users and Click Import.

The users will be available in Deployer project target as normal AD users.

Find and View Items

Viewing Item Properties

You can view the metadata properties or other attributes of various objects in Tzunami Deployer. The Properties window displays the properties of the currently selected item. If more than one item is selected, a property whose value is not the same for all items appears empty. Editing such a property affects all the selected items. Read-only properties are grayed out in the Properties window. The Properties window can remain open while you work in the Project window.

To view an object’s properties:

• Right-click an item and select Properties.

Or

Click .

Or

Press F4.

The Properties window appears.

Figure 46: Properties Window

Only items that appear in Bold can be edited. You can modify user or multi user type properties (For e.g. Created By, Modified By) from Select People window.

To modify user type properties

1. Select the user type property and click   button in Properties window. The Search People window will appears.
2. Click Search and select users that you want to add and then click Add->.
3. Click OK.

Finding Item Versions

You can view the versions of various items in Tzunami Deployer. The Versions window displays the properties of each version of the item.

To view an item’s versions:

• Right-click an item and select Versions.

The Versions window appears.

Figure 47: Versions Window

Finding Items

You can find one or more items in a project. The Find window enables you to find items based on different criteria and properties.

To find items:

• Select View > Find > Find or Find All.

The Find window appears.

Figure 48: Find Window

Table 8: Find window Fields

Deploying Source Data for Migration

The deployment stage specifies which source folders, files, and items are to be migrated to which SharePoint site collections, sites, lists, and folders on the target SharePoint server. Similar to the modeling stage, Tzunami Deployer does not immediately migrate the source items to the SharePoint server during deployment, but only stores the migration instructions in the current Tzunami Deployer project. The Tzunami Deployer content migration changes are only applied to the target SharePoint server in the committing stage. For more information about committing, see Committing the Migration on page 4-84.

In the modeling stage, you can define the SharePoint structure into which you can deploy the source folders and files. If you wish, you can design and define the entire model of the SharePoint structure and only then deploy your first folders and files. Alternatively, you can iteratively design parts of the SharePoint structure, deploy the items into those parts and then go back and repeat this process as many times as required.

In some cases, not all source items are to be migrated. For example, executable files such as EXE and DLL are usually not stored in SharePoint. In other cases, the target location for items is determined by their metadata properties. For example, you may want items created in the year 2001 to be placed in a corresponding folder in SharePoint. In both cases, you can filter the source so that only relevant items will be affected by the current deployment operation. For more information, see Filtering Source Itemson page 4-81.

After completing the deployment stage, the target items appear with an upload overlay ( ). To remove the item assignment, find the location in which the item is deployed (in the target SharePoint) and delete it. For information about finding deployment locations, see Managing the Deployment Processon page 4-80.

The following steps describe how to deploy source items to a target SharePoint:

• Select the actual items to be deployed from the source to the target SharePoint. For more information, see Deploying Selected Source Items to a Target SharePoint Locations on page 4-60.
• Specify the various deployment options, related to structure, files, and security, using the Deploy Wizard. For more information, see Defining Deployment Options on page 4-61.
• Keep track of the deployment process to ensure that you have deployed all the items that are required. For more information, see Managing the Deployment Process on page 4-80.

SharePoint imposes some character and length limitations on item names. For more information, see Folder and File Naming Considerations on page I or refer to your SharePoint documentation. Tzunami Deployer may rename folders or documents by replacing invalid characters with an underscore (_).

Deploying Selected Source Items to a Target SharePoint Locations

When you select to deploy a source item to a target SharePoint item, some items may not be deployed for the following reasons:

• The file extension appears in the blocked extensions list, as defined by the SharePoint administrator (For Example: .exe, .bat, .mdb, and so on). You can ignore this warning and deploy the items. However, the commit will fail unless the items are renamed or the SharePoint server is modified to accept the files.
• The item has already been deployed into SharePoint. Tzunami Deployer does not allow the same item to be deployed more than once into SharePoint.

To select the source items and target locations:

1. In the top half of the Project window, select the source files or folders to be deployed.
2. Drag the selected items to the target location in the SharePoint, in the bottom half of the Project window.

Or

Right-click the selected items in the source store and select Deploy to. The Target items window appears displaying the target SharePoint store.

3. Select the target location and click OK.

The Deploy Wizard appears (Figure 49).

	Tzunami recommends that you to drag and drop selected items. By this stage, you should already know exactly what you are dragging, where you are dragging to, as what (site, list, or document), and which properties you want to add.
	Tzunami Deployer may inform you that some items will not be deployed. You can display these items by clicking Yes.

Defining Deployment Options

After selecting the source items and target location for deployment, the next step is to define the behavior of the deployment. This is done using the Deploy wizard, which guides you through the following:

• Specify how Tzunami Deployer handles item versions, duplicate names, and lists. For more information, see Defining Global Settings on page 4-63.
• Specify whether source folders are created in the target SharePoint as sites, lists, or folders, and how subfolders and content items be handled. For more information, see Defining the Deployment Structureon page 4-65.
• Map source users and groups to the appropriate corresponding users and groups used in the target SharePoint. For more information, see Mapping Security Information on page 4-75.
• Map source security permissions and roles to the appropriate SharePoint roles / permission-levels. For more information, see Mapping Security Information on page 4-75.
• Map source metadata properties to the appropriate columns in the target SharePoint. For more information, see Mapping Properties on page 4-67.
• Map source item property values to the appropriate property values in the target SharePoint. For more information, see Mapping Property Values on page4-72.
• Complete the deployment process. For more information, see Completing the Deployment Process on page 4-73.

Figure 49: Deploy Wizard

To define the deployment behavior:

1. Select one or more of the following deployment options:

• Deploy structure – Copies the source content folder hierarchy to the target SharePoint. If no folders are selected for deployment, this option is disabled. If the target location cannot directly contain files, for example a SharePoint site, this option is selected and cannot be modified.
• Deploy files – Copies the source files and items to the target SharePoint. If only files and items are selected for deployment, this option is selected and cannot be modified.
• Deploy security – Copies source content security settings to the target SharePoint.

2. Click Next. The Deploy wizard displays the Global Settings screen (Figure 50).

Defining Global Settings

You can define the global setting of items, lists and advanced folder hierarchy in the Global Setting Screen.

Figure 50: Deploy Wizard - Global Settings Items

This screen adds a numeric suffix to new item, skips item with matches or overwrite matching items when deploying some files with the same name that might be deployed to the same folder.

To define the Global Setting Items:

3. Select the various global setting items from Items Tab and according to the information in the following table.

Table 9: Deploy Wizard –Global Settings Items

Figure 51: Deploy Wizard - Global Setting Lists

To define the Global Setting Lists:

4. Select the various global setting lists from Lists Tab and according to the information in the following table.

Table 10: Deploy Wizard - Global Setting Lists

Figure 52: Deploy Wizard - Global Setting Lists

This screen enables you to create folder hierarchy by grouping the files based on the selected property into a folder.  For e.g. if an organizations have documents in a folder are separated by the ‘Document Type’ property according to the departments (Marketing, Sales, HR, Account, Finance, etc.). When deploying, a new folder will be created for each ‘Document Type’ property and all documents the same property at that level will be migration into the new folders (Marketing, Sales, HR, Account, Finance etc.). 

To define the Advance Global Settings

5. Select Folder Hierarchy Creation to select property of folder.

6. Select Folder Property and Click Next. The Deploy wizard displays the Define deployment structure screen (Figure 53).

Defining the Deployment Structure

You can define the deployment behavior of folders and container hierarchies in the Define deployment structure screen. The options in this screen differ according to the type of SharePoint target location into which you are deploying. In addition, the type of item you select in the tree determines the options in the Set selected item parameters area.

For example:

• When deploying into a folder or a list, you can only create sub-folders.
• When deploying into a site, you can create sub-sites or lists.

The configuration that you set for any item overrides the configuration of its sub‑items. For e.g. when deploying into a site, if you deploy a folder as a library, you can deploy its sub‑folders only as sub-folders of the library, and not as sub-sites.

Figure 53: Define Deployment Structure Screen

This screen enables you to specify which type of items will be created in SharePoint and to set various deployment parameters. You can select and configure each branch of the deployment structure tree. For e.g. you can specify that a folder from the source file system is deployed as a new site, and that its sub-folders are deployed either as sub‑sites of the new site, as lists of that site, or as sub folders of the new site’s default document library.

To define the deployment structure:

1. Define the deployment structure options according to the information in the following table.

Table 11: Deploy Wizard – Items Handling Window Fields

Field	Description
Deployment structure tree	Select the item for which to define deployment configuration.
Set selected item parameters	Select the type of item to create in SharePoint: Folder List Site Portal area. (Available only in SPS2003, and only when the target location is a descendant of the Home Area.)     When deploying as a list you must select the appropriate list template from the available templates in the site. When deploying as a site, you must enter the site properties, as explained in Creating a New Site on page 4-36.
Deploy hierarchy	Select this option to deploy all sub-folders. If you do not select this option, only the folder whose options are currently edited and its content will be deployed. No sub-folders (and no items in the sub-folders) are deployed.
Deploy items	Select this option to deploy the files and items in each source folder. Selecting this option affects only the selected folder, not its sub-folders. If you do not select this option, only the sub-folder hierarchy is created and no documents are deployed to the target location. When selected, a Documents branch ( ) appears under the folder in the deployment structure tree.
Flat deploy	Select this option to ignore the source folder hierarchy and create a flat structure in which all documents in the source folder and its sub-folders are deployed to the same target location. This option is only available if Deploy hierarchy is selected. When selected, an All Documents branch ( ) appears under the folder in the deployment structure tree and all sub-folders are hidden.

2. Click Next. If Security is deployed, the Deploy wizard displays the Map source users and groups screen (Figure 59). If Security is not deployed, the Deploy wizard displays the Property Mapping screen (Figure 54). For more information, see Mapping Properties on page 4-67.

Mapping Properties

Items are associated with metadata properties (sometimes referred to as fields or attributes), such as creation date, last modification date, author, title, keywords, status, and so on.

When the source property set (sometimes referred to as category or profile) does not match the target SharePoint property set (the columns in the target list or folder), Tzunami Deployer requests information regarding the mapping of source properties to target properties. The Property Mapping screen appears, as shown below. Properties with the same name and matching types are automatically matched and appear in the Mapped Properties area, as well as previously mapped properties.

Tzunami Deployer has an ability to add Content Types (that already exists on the Target Site Collection) to the lists/libraries during deployment.  For more information, see Adding Content Type on page 4-69.

If any source properties cannot be matched to any target property, a yellow notification bar at the top of the screen indicates that the target has fewer properties than the source. This may indicate that you might lose data, since source information is not deployed to target SharePoint columns. You can click the link in the notification bar to automatically add properties to your target SharePoint list. For more information, see Automatically Adding Propertieson page 4-71. Alternatively, you can manually add the missing columns before starting the deployment process. For more information, see Modeling SharePoint Metadata Service on page 4-41.

Figure 54: Property Mapping Screen

To map properties:

1. Click Add Content Type and select the Content Type from the list. Repeat this step for each property you wish to add Content Type.

2. Select a source property and its corresponding target property and click Map. Repeat this step for each property you wish to map. The mapping is displayed in the bottom of the screen.

If the source items use several different property sets, For e.g. documents with different profiles, or when deploying to several targets with different property sets or lists of different types, this step is repeated for each pair of source and target property sets. Clicking Import/Export enables you to create a property mapping XML file, according to your current mappings, or load a different property mapping XML file. You can generate your own mappings (using Excel, or any other tool that generates XML files) and import the XML file. For more information about property mapping XML files, see Sample Property Mapping XML Fileon page 5-116.

3. Click Next. The Deploy wizard displays the Value Mapping screen (Figure 57).

If you map properties of different types to each other (For e.g. a text property to a numeric property), a warning message is displayed. Clicking Yes instructs Tzunami Deployer to convert the values. If Tzunami Deployer fails, it assigns an empty value to the target property. Clicking No returns you to the Property Mapping screen, in which you must change the mapping. For user-type properties, such as Created By or Modified By, or for choice properties, the Map Property Values screens appear. In these screens you can map the values of choice type properties, if required. For more information, see Mapping Property Values on page 4-72.

Adding Content Type

Tzunami Deployer enables you to add Content Type to target during deployment. The Adding Content Type to Target window shows the list of Content Type from the Target Site collection, which allows you to select one or more Content Type from the lists that you want to add in lists\libraries during deployment. The added Content Types that you selected in this window will be available in the Content Type Value Mapping screen.

Figure 55: Adding Content Type To Target Window

To add content type

1. Select the various options according to the information in the following table.

Table 12: Adding Content Type to Target Window Fields

2. Click OK.

The added content type properties are displayed in the Property Mapping Screen (Figure 54).

Just like other property values, You can map Source and Target Content Type values from the Content Type Value Mapping screen. For more information on Value Mapping, see Mapping Property Values on page 4-72.     If a source content type is mapped to target, then the mapped source Content Type will not be added i.e. mapped target Content Type values will be added to the target lists\libraries. If there are any unmapped source Content Type values, then it will be added to the target lists\libraries with its related fields. If there are any unmapped target Content Type values, then it will be added to the target lists\libraries with its related fields.

Automatically Adding Properties

Tzunami Deployer enables you to automatically create the missing columns in your target SharePoint list if it has fewer properties than your source. The Missing Properties in Target window lists the properties that were not mapped and offers to create respective columns in the target. All the source properties that you select in this window are automatically mapped to their corresponding newly created SharePoint columns.

Figure 56: Missing Properties in Target Window

To automatically create and map properties:

1. Select the various options according to the information in the following table.

Table 13: Missing Properties in Target Window Fields

2. Click OK.

The added target properties are automatically mapped with the respective source properties and are displayed in the Property Mapping screen (Figure 54).

If you add missing properties, the target location is modified (columns are added to it). As is the case with other modifications, a pencil overlay appears on the target location. For example, . All property and value mappings that you perform are stored in the Tzunami Deployer project so that the next time you map from the same source property set to the same target property set or the same values appear in the source items, Tzunami Deployer automatically maps them. If all properties and values are successfully mapped by Tzunami Deployer, the Value Mapping steps may not be displayed. You can determine if these steps are displayed in the Options window. For more information about the Options window, see Defining Deployment Options on page 4-61.

Mapping Property Values

In order to assign values to choice properties (properties that offer a list of specific possible values, For e.g. Status) and user properties (such as Created By and Modified By), Tzunami Deployer enables you to map values from the source items to specific target choice values.

After you map properties, as described in the previous section, the Value Mapping screen appears, once for users and once for each choice (and multi-choice) property in the target locations.

Figure 57: Value Mapping Screen

This screen displays the source property and valid target property values, as well as any existing mappings.

The Properties window can remain open while you work in the Project window. It reflects the properties of the currently selected item or items. If the !<default>! value is mapped, you can leave source values unmapped. When deploying an item whose property value is unmapped, the corresponding deployed item property will be assigned with the same value as the !<default>!. If the !<default>! value is not mapped to a target value, all source values must be mapped. Properties that are not marked as required can be assigned an empty value by mapping the source value to !<empty>!. To instruct Tzunami Deployer to assign an empty value in all cases, map!<default>! to !<empty>!. Another special target value is !<Keep Original>!, which appears only if the target property allows fill-in values. Fill-in values enable you to add a value even if it is not included in the list of values). After the new deployed items are created in the target SharePoint, you can override the values assigned to them in the Value Mapping step by using the Properties window. For more information, see Viewing Item Properties on page 4-56 and Editing Properties of SharePoint Item on page 4-38.

To map source property values to target property values:

1. Select a source property value and a corresponding target property value and click Map. Repeat this step for all the property values you wish to map. The mapping is displayed in the bottom of the screen.

When handling long lists of values, you can enter a sub-string in the Filter fields. All values that do not contain this sub-string will be filtered from the corresponding list.

2. Click Next.

This Value Mapping screen will reappear for each mapped target choice (and multi-choice) property, as well as once for User type properties. When all source property values are mapped, the Deploy wizard displays the Ready to deploy screen.

If you selected to add unmapped values as legal target property values, the unmapped source values will be added to the legal values list of the property. Clicking Import/Export enables you to create a property mapping XML file, according to your current mappings, or load a different property mapping XML file. You can generate your own mappings (using Excel, or any other tool that generates XML files) and import the XML file. For more information about property mapping XML files, see Sample Property Mapping XML Fileon page 5-116.

Completing the Deployment Process

Tzunami Deployer is now ready to deploy the source items into the target SharePoint.

Figure 58: Ready To Deploy Screen

If Tzunami Deployer encounters errors or deployment failures, these errors are displayed in the deployment report and are announced in the next step of the wizard.

To complete the deployment process:

1. Click Next. Tzunami Deployer begins deploying your source items into your target SharePoint.

When the structure is created and the documents are added, the Ready to deploy screen displays a link to view the deployment report. If any warnings or errors were generated as part of the deployment process, icons with the relevant number of errors/warnings appear.

Tzunami recommends that you review this report carefully and search for any warnings.

2. Click Next. The Deploy wizard displays the Deploy security screen.

3. Click Next. The security deployment process begins.

The Properties window can remain open while you work in the Project window. It reflects the properties of the currently selected item or items. You can skip the security deployment and manage the security at another time unchecking the Deploy security checkbox (Available only when migrating to SharePoint 2003) in the Deploy Wizard (Figure 49). The Security Deployment report is stored in the following directory: <Project Folder>\Reports\Security Deploy Report.<Date>.<Time>.xml. This report exists only when migrating to SPS2003, in which case a link to the report is displayed.

When Tzunami Deployer finishes deploying all items and settings, the Deploy wizard displays the Thank you screen.

4. Click Done. The new items are displayed in the bottom half of the Project window.

Mapping Security Information

The first page of the Deploy Wizard contains the Deploy Security checkbox. Selecting this checkbox enables you to also deploy the source security settings for your deployed containers and items.

If you select the Deploy Security checkbox, the following screens are added to the wizard:

• Groups mapping – Mapping of source groups to target groups as containers of users.
• Entities mapping – The concrete user mapping.
• Roles Mapping – Mapping of source roles (permissions sets) to target roles.

In the following example we review a deployment from LiveLink to MOSS.

Assuming we would like to deploy the following hierarchy as a Document Library into MOSS:

Tzunami Deployer uses the concept of security roles, each representing a set of permissions. If the source system supports this concept, the roles are read from the system. Otherwise, Tzunami Deployer generates its own roles. You can add, remove and modify the roles used.

David’s set of permissions qualify him the role of Contributor on the Documents folder and its content, but qualifies as an Administrator on Sub Folder and its child item. Ron’s role is Web Designer on all the hierarchy and Test Group has the role of Reader on all content except for Documents, in which he is a Contributor.

Groups Mapping

Figure 59: Group Mapping screen

The screen consists of three lists:

• Source groups – The source groups that are relevant to the items deployed.
• Target groups – The target groups that are relevant to the site into which we deploy.
• Mapped – Pairs consist of source groups and target groups that are already mapped.

In this step you can map a source group either to an existing site group, or to create a new site group bearing the same name.

In our example, we have only one source group (Test Group), and in the target we have the three default site groups (Members, Owners, and Visitors) and one user-created group named Target Group. We will map Test Group to Target Group. This means the members of Test Group will be added as members of the Target Group.

If the source is File System, this step is absent, since File System groups are treated as Active Directory groups, which can be mapped to SharePoint users (see Entities Mappingon page 4-77).

Entities Mapping

Figure 60: Entities Mapping screen

This screen also consists of three lists:

• Source users & groups – The source users and groups that are relevant to the specific items deployed. Included are users belonging to the groups.
• Target users & groups – All the local and domain users in the target. This means that also users that are not relevant to the target site are included (if you map to these users, they will be added to the target site).
• Mapped – Pairs consist of source user or group and target user or group each, that were already mapped.

In this step you can map each source user or group to a target user or group.

Mapping a source entity to a target entity means that the target entity will receive the same permissions that the source entity has. These permissions will be assigned based on the role mapping step (see Role Mapping on page 4-77). Also, when Tzunami Deployer performs the group mapping, group membership is migrated based on the entities mapping.

You can use the Filter field in order to drill down to a specific name. Tzunami Deployer suggests some of the mappings based on the user names. Also Tzunami Deployer suggests the mapping of groups based on our mapping on the previous screen.

Role Mapping

After mapping the default user and the other users you wished to map, click Next to get to the third security screen: Role Mapping:

Figure 61: Role Mapping screen

This screen contains three lists:

• Source roles – The source roles (each role is a permissions set).
• Target users & groups – Target roles. You can select more than one target role.
• Mapped – Pairs consist of a source role and its mapped target role(s).

Roles, as mentioned earlier, are sets of permissions. In this step you map a source role to a target role. This means that target entities that were mapped to a source entity with a certain role will be assigned with the corresponding role that will be mapped in this screen.

A sensible mapping would be: Administrator > Full Control, Contributor > Contribute, Reader > Read, Web Designer > Design.

You can check more than one target role. When migrating from WSS2.0/SPS2003, Site groups are handled as both groups (containers of users), and roles (sets of permissions). This means that Site groups will appear in both the Groups mapping and the Roles mapping steps.

Following our example, the outcome of our security mapping will be:

Checking Deployed Items

Once you have finished the deployment, you can scan the hierarchy of items and search for problematic items.

To find problematic items:

• Select View > Find > Find Problems.

Tzunami Deployer scans the hierarchy in the target system for problematic items. If there are no problematic items, a message is shown. If Tzunami Deployer encounters problematic items, the Problematic Items window appears (Figure 62).

The window updates itself as you modify items to handle their problems. You can double-click (or click Go To) on an item to navigate to it directly. Click Copy to clipboard and Export to retrieve the list of problematic items.

The following problems are checked:

• Name contains invalid character.
• Name and URL are too long
• Blocked extensions
• Files are too large
• Properties values are legal (Hyperlinks start with a protocol schema, required properties have values, required properties do not have a default value).

Figure 62: Problematic items window

Managing the Deployment Process

This section describes a variety of options that enable you to keep track of the deployment process. For e.g., you can determine which source items are deployed to which target locations:

• Item Counters – Items in the container versus the number of items deployed. For example, the following shows that only one item of the 25 in this hierarchy is deployed:

The first number is the number of files and items deployed, but not yet committed to the target SharePoint. The second number is the total number of files and items in that particular location and all its nested hierarchy. In the source system, this enables you to verify that all files intended for migration were indeed deployed. In the target SharePoint system, this indicates how many items currently in the specific location were deployed but were not yet committed to SharePoint.

• Icon Overlays – Each item or folder can only be deployed once. After deployment, the icons of both source and target items appear with an upload overlay ( ). For e.g.  .

If you try to redeploy an item that is already deployed, a message is displayed. You can remove a deployed item by finding the location to which the item is deployed (in the target SharePoint) and delete it.

• Find Source/Target Tool – You can find the correlation between items in the source and their new location in the target:
  • Select a source item and click  Find Source/Target to find the deployed target item.
  • Select a target item and click  Find Source/Target to find the deployed source item.
• Deployed To / Deployed From Column – The source includes a Deployed To column that specifies the address of new item in the target SharePoint. The target SharePoint includes a Deployed From column that specifies the address of the source item that was deployed.
• Find Problems – You can instruct Tzunami Deployer to search for known problems (such as long URLs, which is a SharePoint limitation, blocked extensions, and so on) by selecting View > Find > Find Problems. This option can only be performed before the committing stage, on uncommitted items.

• Deployment Report – Before committing your changes, you can view a report of the deployed items. Tzunami recommends that you review the Deployment Report carefully and search for any warnings. The Deployment Report is stored in the following directory: 
  <Project Folder>\Reports\DeployReport.<Date>.<Time>.xml.
• Filtering Source Items – Tzunami Deployer enables you to filter the items that appear in the source system. For more information, seeFiltering Source Items on page 4-81.

Filtering Source Items

When you apply a filter to a folder, the filter is automatically applied to all sub-folders. You can set a different filter for a sub-folder or disable filtering for it altogether by editing the sub-folder’s filter settings.

To filter the source store list:

1. Click .

Or

Right-click a source folder you wish to filter and select Filter.

The Edit Filter window appears.

Figure 63: Edit Filter Window

2. Select a property from the list of Properties.

3. In the Condition area, select one of the following conditions from the drop-down list and enter a value in the corresponding field(s):

• Equals to
• Different than
• Greater than
• Smaller than
• Between
• Matches
• Doesn’t match
• Empty Value
• Non Empty Value

Some conditions have single values and others have multiple values, for example the Equals to condition can contain up to five values.

 4. Click Add Condition. The condition is added to the Filter area, displaying the full filter expression.

You can only add one condition per property. You can edit a condition for a property by selecting the property and modifying the condition type or it’s currently assigned values and clicking Add Condition. You can remove a condition from a property or all the conditions from all the properties by clicking Clear Condition or Clear All, respectively.

5.  Click Import/Export Button. Export button can be pressed to dump added filter condition as an XML file. Likewise, Import button can be pressed to import the saved filter conditions accordingly.

6. Click OK. The filter is applied to the source hierarchy and the icon at the filtered location, including all its sub-folders, includes a filter overlay ( ), as well as an additional counter specifying the number of files and items that passed the filtering.

Best Practice for deploying source

• Drag and drop:Deploy selected items from the source to a pre-determined location in the target. At this stage of the Deployment, you should already be aware of what you’re dragging (site, list, etc.) and which properties you want to add accordingly.
• Mass Deploy:Repeat the “Drag and Drop” phase for as many projects as you like. Keep in mind that using more than one person to conduct the migration can help you move through the different phases simultaneously and thereby at a quicker pace.

Make sure not to deploy the same site collection using two different projects that are destined to run simultaneously, as this could cause inconsistency issues.

• Review the Deploy Reports for any warnings
• Check for problems before commit: Before committing your project to SharePoint, use the “find problems” option from the Deployer menu (Ctrl +P) in order to identify any issues that may occur as a result of SharePoint limitations, such as long URLs, or blocked extensions.
• SharePoint Limitations: Keep in mind SharePoint column limitations while adding missing properties.
• Multiple Deployment: Simulate multiple deployments for a source type till you find the one that suits your needs best. Use the same deployment pattern for that item type in future.

Committing the Migration

The committing stage executes your target SharePoint customizations and migrates your source items to your target SharePoint. You can perform the committing stage immediately after deployment or you can schedule it for a later date. For more information, see Schedule Commit on page 4-86 and Batch Mode Commit on page 4-88.

The committing process first applies the model that was designed in Modeling SharePoint Targets on page 4-35. This ensures that the sites, libraries, lists, and folders are created in the target SharePoint and that their metadata is set, so that they are ready for the migration of items into them, according to the deployment scheme you built in Deploying Source Data for Migration on page 4-59.

The actual content migration physically copies the source items (For e.g. Microsoft Office documents) to the target library, list, or folder on the SharePoint site, while updating their metadata properties according to the Tzunami Deployer project definitions.

You can estimate how much time the committing stage requires with the following calculation:

(  X  x  Y  )   

(  N  x  Z )       = anticipated committing time.

Where:

X – The total number of documents to commit.

Y – The average committing rate for one Tzunami Deployer instance. This rate can be determined by committing a project and dividing the number of documents by the amount of hours taken to complete committing.

Z – The number of servers (that meet the required specifications) available on which to run Tzunami Deployer.

N –                 The number of Tzunami Deployer instances planned to run on each server.

While your projects are in the committing stage, create and work on additional projects to save time. When one project finishes the committing stage, you can immediately begin committing another. You can run multiple Tzunami Deployer projects on a single server. Keep in mind that the number of Tzunami Deployer projects running simultaneously on one machine and the total number of running projects depends on your hardware, network connections, and the SharePoint environment maintenance and response time. This maintenance and response time depends on the amount of free memory on the machines running Tzunami Deployer, hardware, available CPU, network connectivity to SharePoint, DB indices on the SharePoint SQL server, and so on. Avoid making additional changes directly to your target SharePoint during the committing stage.

After the committing stage is complete, the numbers on the left of the item counters in both the source and target trees are set to zero and the New, Modified, and Deployed overlays are removed from all icons.

Committing Now

To commit the changes to the SharePoint server:

1. Select Data > Target SharePoint 2003/2007/2010/2013/SP Remote/Office 365 > Commit to SharePoint.

Or

Click 

Or

Right-click in the target SharePoint store area and select Commit to SharePoint.

If the Tzunami Deployer project was modified since it was last saved, Tzunami Deployer informs you that the current project data will be saved.

Tzunami Deployer prompts you to verify that you wish to commit your changes to SharePoint.

2. Click Yes. Tzunami Deployer begins committing your changes and displays a progress window indicating the number of modifications being made to the SharePoint server, as well as the progress and time estimation.

Figure 64: Commit Progress Window

Clicking Errors only filters the displayed progress messages to show error messages only. After Tzunami Deployer finishes committing your changes, you can right-click the new SharePoint site or document library and select Open to view the site or document library using your Internet browser.

If the committing process completes successfully without errors, you have finished migrating your content.

If errors or failures are displayed in the Commit Progress window (Figure 64), a new tab is added to the window, indicating which items were not committed and what problems caused the failure.

3. Click the Commands tab. The Commands tab appears listing the actions that failed to be committed to SharePoint and the reason for the failure. All actions are selected by default.

Figure 65: Commit Window – Commands Tab

 4. Select the actions that you want to retry committing to SharePoint and click Try Again.

If you close the window without resolving the failed commands, you can resolve them later by right-clicking in the SharePoint store and selecting View pending commands. You can then retry committing the items.

Schedule Commit

You can schedule Tzunami Deployer to commit a project at a time that is most convenient for you.

To schedule Deployer project:

Once you have successfully deployed contents to the target, save the Deployer project.

1. Select Data > Target SharePoint 2013> Schedule Commit to SharePoint 2013.

Or

Click 

Or

Right-click in the target SharePoint store area and select Schedule Commit to SharePoint 2013/SP Remote/Office 365.Check this

The Schedule Commit window appears.

Figure 66: Schedule Commit window

Table 14: Schedule Commit

Parameters	Descriptions
Start	Set the start date and time for schedule commit.   The start date and time should be greater than current date and time.
Mode	Enables you to specify how Deployer runs the schedule commit process. Mini GUI - Runs Deployer and starts to commit a project opening the Mini Deployer interface. It shows commit progress, Elapsed time and Time left (estimation) in Mini Deployer window. No GUI - Runs Deployer and starts to commit without opening the user interface of Deployer.
Send Email Notification	Enables you to send email notifications after commit is completed.
SMTP Server	Enter the outgoing (SMTP) e-mail server.
From	Enter the sender’s email address in the From box.
To	Enter the recipient's email address in the To box. Enter multiple addresses by separating them with a comma.

 2. Click Save.

Please ensure that the Project File is not opened in any Deployer instances during the scheduled time.

Batch Mode Commit

With Task Scheduler, you can schedule Tzunami Deployer to commit a project at a time that is most convenient for you.

To set a time for committing a project:

Once you have successfully deployed contents to the target, save and close the Deployer project.

1. Create a batch file with commit command in the following format.

Deployer.exe <DeployerProjectFile> [/commit [/nogui] [/minigui]] [/SMTP <mail.domain.com>] [/From <name@domain.com>][/To <name@domain.com>]

Usage

For example:

C:\> “C:\Program Files (x86)\Tzunami\Deployer\Deployer.exe” “F:\My Project\Project1.tde” /commit

C:\Program Files (x86)\Tzunami\Deployer> Deployer.exe “F:\My Project\Project1.tde” /commit /nogui

C:\Program Files (x86)\Tzunami\Deployer> Deployer.exe “F:\My Project\Project1.tde” /commit /minigui

C:\> “C:\Program Files (x86)\Tzunami\Deployer\Deployer.exe”  “F:\My Project\Project1.tde”  /commit /nogui /SMTP mail.friendsco.com /From info@friendsco.com /Toadmin@friendsco.com

For better performance and less intrusions on the machine, you can use the /nogui flag, which does not display the Tzunami Deployer user interface.

The first parameter is the path to Deployer executable file. 

Save the file.

2. Run the batch file in the task scheduler. For more information about task scheduler, refer to:

http://technet.microsoft.com/en-us/library/cc748993.aspx.

Best Practice for Committing a Deployer Project

• Check for problems before commit
• Start committing the projects:While these projects are committing, begin creating as many new Deployer projects as you can.
• Run several Deployer instances on one server:The number of Deployer projects running simultaneously on one machine and the total number of projects which can run simultaneously depend on your hardware, network connection and SharePoint environment maintenance and response time (free memory on the machines running Deployer, HD availability, CPU, network connectivity to the SharePoint farm, DB indices on the SharePoint SQL server, etc.).
• Don’t waste time:You can immediately commit another project as soon as the previous project finishes committing. You also have the option to schedule a commit in the future through the use of the Microsoft Windows Task Scheduler combined with Deployer’s command line capabilities. Keep in mind SharePoint column limitations while adding missing properties.
• Avoid performing changes to the SharePoint outside of Deployer during the commit phase.
• In order to produce a rough estimation on the duration of the Commit Phase, verify the following environment-dependent variables:
  • X: Total number of documents to commit
  • Y: Average commit rate for one Deployer instance. Test this once with one project committing M documents for H hours and just do a simple calculation of M/H.
  • Z: Number of servers available to run Deployer
  • N: Number of Deployer instances designated to run on each server.

It is not recommended to run more than 3 Deployer instances on a single server.

Rough time estimation for the duration of the commit process can be calculating using these parameters:

(  X  x  Y  )

(  N  x  Z  )

• Schedule Commit: With Scheduled Commit, you can schedule Tzunami Deployer to commit a project at a time that is most convenient for you.

• Identify Issues: During commit, or any other phase of the migration project, identify any problems that may arise. Save the export/deploy/commit reports and logs which contain any warnings or errors. Notify the Tzunami Support Team about these issues.
  
  

Test