COMERCIALES DEL ECUADOR EN LA CAN
LUCHA CONTRA LA CORRUPCIÓN
User profiles are among the most important aspects in MOSS 2007, and it is equally important to know about how they are managed during the upgrade process. In SharePoint 2010, two important services will facilitate user profiles: user profile service and managed metadata service. During an in-place upgrade, these two services will take care of your user profiles and taxonomy. The MOSS 2007 SSP database will be upgraded to a new user profile database. After the upgrade is complete, you can run the Move-SPProfileManagedMetadataProperty PowerShell cmdlet for the taxonomy to be used by the
managed metadata service.
In case of database attach upgrade, you will have to first configure a managed metadata service before you can actually use the upgraded taxonomy and profiles. You then have to attach the SSP database and copy the taxonomy data into taxonomy database for use by your managed metadata service. To do so, you can run the Move-SPProfileManagedMetadataProperty PowerShell cmdlet before you actually use the taxonomy.
Note When you upgrade, timer jobs will be reset to default schedule setting values. To ensure they are run as
they were before upgrading, we recommend to take note of them and resetting them after the upgrade.
Finally, properties related to profiles that are stored in the configuration database are not upgraded during the database attach upgrade, although they are preserved during an in-place upgrade. Here are the persisted properties that will not be upgraded using the database attach model:
• MySiteHostURL • SearchCenterURL • EnablePersonalFeaturesforMultipleDeployments • ProfileStoreLanguage • ProfileStoreLanguagePacksApplied • ProfileStoreCollationID • DaysWorthOfEventsToKeep
SSO to SSS
Single sign-on (SSO) has been taken to the next level of enhancements in SharePoint 2010 and is now called Secure Store Services (SSS). SSO in Excel services and BDC are typically used in various scenarios to avoid the double-hop issues. In SharePoint 2010, you will create an unattended service account that would be used in SSS and assigned to a particular service application as Application ID. This service account will take care of impersonating the user to access the backend systems.
Note Logged-in user credentials are used to impersonate to only some extent and windows will not forward
these credentials to a remote resource (requires a second hop). Hence the user’s identity is lost even before it
reaches the back end. This is known as double hop issue. This requires a mechanism to impersonate logged-in
user with the back end which is achieved by using Secure Store Services in SharePoint 2010.
You can configure SSS by following these steps:
1. Launch secure store services configuration by selecting CA ➤ Application Management ➤ Service Applications ➤ Manage Service Applications ➤ Secure Store Services.
2. Before you can configure, you have to create a new key to encrypt the
passwords that you store as part of this service. Once you successfully create a new pass phrase for the key, click the New menu on the ribbon, and create new Target Application Settings, as shown in Figure 2-5.
CHAPTER 2 MIGRATION FOR THE IT ADMINISTRATOR
Figure 2-5. Configuring secure store service application ID settings
3. Click Next to furnish the details on the Target Application Settings window, and then provide field names User Name and Password in the following screen.
4. Ensure you choose the accurate Field Type (Windows or a specific account for instance).
5. In the following screen, provide Target Application Administrator(s), and click OK.
6. Once the target application ID is successfully created, SharePoint will return to Manage Target Applications window.
7. Select the previously created Target Application ID, and click the Set menu under the Credentials section to launch the Set Credential window, shown in Figure 2-6.
8. Provide the credential information, and click OK.
9. You application ID is technically ready after successful authentication of the account. You can use this application ID and set it to any service applications application ID.
Figure 2-6. Set credentials for the target application ID
Tip For more information on Secure Store Service (SSS), please see Chapter 12 of Building Solutions with
SharePoint 2010 by Sahil Malik (Apress, 2010).
Creating an SSS application ID is very important during the upgrade process, because there is no direct upgrade from SSO to SSS. You will have to configure SSS first and then configure the applications to use this SSS application ID instead of your SSO configuration. However, you can migrate data from the SSO database to SSS database. Once you provision a new SSS application ID using unattended service account, you can upgrade your SSO database using the following PowerShell cmdlet: Upgrade-SPSingleSignOnDatabase –SSOConnectionString <connectionString> -
SecureStoreConnectionString <secureStoreConnectionString> -SecureStorePassphrase <passphrase> where connectionString is the database connection string to your existing SSO database,
secureStoreConnectionString is the database connection string to your new SSS database, and passphrase is the security phrase you choose before creating any application ID.
Once the upgrade is successful, disable the SSO service use the following PowerShell cmdlet: Disable-SPSingleSignOn –ServerName <serverName>
CHAPTER 2 MIGRATION FOR THE IT ADMINISTRATOR