What is SkyDrivePro in SharePoint 2013

With the release of SharePoint 2013 came a new feature that has proven to confuse almost everyone, SkyDrive Pro. The confusion lies with another Microsoft product called SkyDrive that is completely unrelated to SharePoint. Confused as well? You’re not the only one and you shouldn’t feel bad about it, I have talked with people that make a living with SharePoint who are just as confused. I am writing this to answer some of the many questions I get when speaking on SharePoint 2013 “What People want from SharePoint 2013”.

First, there was SkyDrive

Let’s start with the one everyone knows, SkyDrive. SkyDrive is free to the public; anyone can have a SkyDrive account it is usually attached to your Hotmail, Live or Outlook.com account.

SkyDrive is a place somewhere in the “cloud” as some would say. Essentially, a place where you can store your files without having to worry about it and Microsoft is taking care of the storage for you. A competitor to the very popular service called Dropbox.

If we try to simply the service, because I could write quite a bit just on SkyDrive, you can put your files there and share them with others. After adding your files on SkyDrive, you assign “Public”, “View” or “View and Edit” permissions and generate a hyperlink for people to access the files or folders. You do have 7GB of storage, though you can always purchase more. There are a few other fun features like commenting on files and folders but this is not the focus of my article.

Do you remember the SharePoint “My Sites”?

These became popular with SharePoint 2010 though in many cases, it wasn’t really used to its full potential. The same goes for SharePoint 2007 where it was even less popular. The way I see it, My Sites is the new “My Documents” found on our computers.

In SharePoint 2013, we still have the concept of My Sites.

SharePoint My Sites:

If activated, it allows users in your organization to have a “personal” environment, sort of speak. It creates a SharePoint Site Collection for every user that uses a My Site. This Site Collection comes with a few things including a Blog subsite, a Tasks List and of course… a Document Library.

Teaser: This Document Library is what some confuse with “SkyDrive Pro”.

The SkyDrive link in the Top Bar of SharePoint 2013

So why did I talk about the My Sites earlier if we are covering SharePoint 2013 SkyDrive Pro exactly? Well, we established that when you create a My Site as a user, you get your own Site Collection, which includes a Site with a Documents Library amongst other things. The SkyDrive hyperlink at the top is just a link to this Document Library.

If you look at this screenshot, you’ll notice that after I clicked on the SkyDrive link, I arrived to my so-called “SkyDrive Pro” which, if we look at the url, really just is my Document Library. Here is the fun part, this is still not SkyDrive Pro, all it is, is a hyperlink with the name SkyDrive to a personal Document Library.

SkyDrive Pro – The document synchronization service

SkyDrive Pro is not really something that comes with SharePoint 2013. It actually comes with Microsoft Office 2013 and very recently as a standalone download from the Microsoft site.

Let’s take the Document Library in our personal My Site for example, which is called SkyDrive Pro in many places. SharePoint 2013 has a new “Sync” button that tells your installed SkyDrive Pro to launch and sync with this document library to make the documents available offline and on your desktop.

Once you click on it, SkyDrive Pro will launch

and will allow you to Sync this Document Library to the specified location.

The result:

So is this SkyDrive Pro?

Well this is what I am trying to explain; SkyDrive Pro isn’t a specific Document Library or place in SharePoint. It’s the service that runs on your computer that does the Sync job for you. You can even launch SkyDrive Pro from the start menu. 

SkyDrive Pro can be used with almost every Document Library

Right now we established that there is a public service called SkyDrive and that there is also a link called SkyDrive in SharePoint that actually points to your Document Library in your My Site. Then, we looked at a “Sync” button that launches your installed SkyDrive Pro service to Sync that Document Library to your Desktop.

But, what about other Document Libraries? 

The Sync button is contextual to the url or where you are when you click it. So if I go to my Team Site and click on Sync, it will want to Sync with the Document Library there. If I go to a specific Document Library and click on Sync, then it will want to Sync with that Library. Let’s see.

The only difference with the Document Library from your My Site is that this one will not be stored under SkyDrive Pro in your Favorites but under SharePoint.

But it’s still SkyDrive Pro on your computer doing everything and making it happen.

Prevent Document Libraries from being sync’ed with SkyDrive Pro

If you do not wish for a Document Library to be available to Sync through SkyDrive Pro, there is an option in the Advanced Settings of a Document Library.

Once set to no, the Sync button for the Document Library will not longer be available.

Launching SkyDrive Pro from your Computer

The SkyDrive Pro client on your computer can also be launched and used to browse your Site and available document Libraries.

Once launched, it will appear in your tray as an icon with blue clouds. You can use it to Sync to a new Library by right clicking and selecting “Sync a new Library”.

This will launch a new menu where you can enter a SharePoint 2013 url and select a Document Library to Sync.

Problem with the terminology and things to know

Let’s try to put everything we learned in an easy summarized view. 

SkyDrive: A free online service offered by Microsoft that lets you store and share files and folders. It has nothing to do with SharePoint. 

My Site: This is not SkyDrive Pro; it’s still your My Site which is a Site Collection owned by the User. 

SkyDrive Pro (the link): In SharePoint 2013 there is a link at the top called SkyDrive which points to the Document Library in your My Site. Once “Sync’ed” it will appear in your Computer by using the application SkyDrive Pro installed by Office 2013 or standalone. This Document Library will appear as “SkyDrive Pro” in your local “Favorites” which can lead to confusion.

The Real SkyDrive Pro: A synchronization service installed by Office 2013 or standalone from the Microsoft download site. Once installed it will allow you to Sync any Document Library from SharePoint 2013 or Office 365 to your Computer. These will then appear in your Windows Explorer under “Favorites”.

Things to know

SkyDrive Pro is not a Migration Tool: Just because you can drag and drop files to SharePoint using SkyDrive Pro does not mean it is a migration tool for content. You will want to preserve the authors and timestamps (created, created by, modified, modified by). This is something SkyDrive Pro will not due while copying your files.

Work Offline: When it Syncs your files from SharePoint 2013 to your Computer, the files are actually copied. This lets users work offline. SkyDrive Pro is the new Groove 2007 and SharePoint Workspace 2010 but simplified. 

Stopping a Sync: Important to know, especially for security reasons is that files that were copied by a Sync with SkyDrive Pro will stay on the users computer once the Sync is stopped.

The real challenge for you

You’ll have to see how you will take on this confusion within your own organization. Microsoft has opted to call the Document Library in your My Site “SkyDrive Pro” in hope to keep the confusion to a minimum no doubt. This would probably help users think of SkyDrive as the free service and SkyDrive Pro a similar service but with files and folders stored in their own corporate Document Library on SharePoint 2013 or even Office 365.

Everything will depend on how you bring this terminology in.  If you are migrating to SharePoint 2013 or Office 365 this is something you’ll want to make sure is understood beforehand by your Power Users.

I wrote this article because I saw a lot of confusion both online and during my conference sessions on SharePoint 2013. I wrote an article “What People want from SharePoint 2013” which covers many other questions and uncertainties I have noticed.

Migration On SharePoint 2007 To 2010

Step 1: Move the site to a new web application in SharePoint 2007

Let's say we want to migrate the SharePoint site at http://duyfarm/TeamSite.

1. First, create a new Web application and blank site collection (for example: http://duyfarm:6789).
   
2. Login to the SharePoint server using an account that has the following rights/permissions:
   • SharePoint Farm Admin.
   • Local Administration rights on the Web server.
   • db_owner permission on the content databases.
   • Make sure the access account has access to the site content (sometimes farm admin might not be a site collection admin).
3. Open Command Prompt and change directory to %COMMONPROGRAMFILES%\Microsoft shared\web server extensions\12\bin, then run the following STSADM commands: stsadm -o export -url <URL name> -filename <export file name> -includeusersecurity

stsadm -o import -filename <import file name> -url <URL name> -includeusersecurity

   

The imported Web application might look like this:

         

Step 2: Copy the content database backup to the SharePoint 2010 SQL server

1. Open Microsoft SQL Server Management Studio. Right-click on the content database and select Tasks > Backup...\
2. 
   
   
3. Enter the Backup Name, select Destination, and click OK to start.
   
   
   
4. Copy this backup file to the SharePoint 2010 SQL server.

Step 3: Mount the content database to the SharePoint 2010 server

1. On the SharePoint 2010 server, create a new empty Web application. For example: http://duyfarm2010:6789.
2. If you have any custom components on the original site, install them to this Web application now.
3. After that, we can restore the SharePoint 2007 backup to SharePoint 2010 SQL Server. Open Microsoft SQL Server Management Studio. Right-click on Databases and select Restore Database...
4. 
   
   
5. Enter the new database name, making sure that you don't overwrite the original content database. Select the Source and click OK to start.
   
   
6. Open SharePoint 2010 Management Shell and dismount the current SP2010 content database.
   Dismount-SPContentDatabase <ContentdBName>
   
   
7. Verify that we have all the needed custom components. If there are any errors, make sure you correct them before mounting the SP2007 content database.
   Test-SPContentDatabase -Name <DatabaseName> -WebApplication <URL>
   
   
8. My test shows no error, so we are ready to run the Mount-SPContentDatabase cmdlet. This cmdlet also upgrades the SP2007 content to SP2010.
   Mount-SPContentDatabase <ContentDb> -WebApplication http://SiteName
   
   
9. After this process has completed, you need to review the log files (the upgraded log file and error log file) to make sure there are no errors. The log files are located at %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS. The logs are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS-error.log and Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds). If there are errors at this time, they will most likely be due to some customization done on the SharePoint 2007 server.

We have finally finished the migration process. Notice that after our upgrade is completed, the new site looks exactly like it was in SharePoint 2007. In SharePoint 2010, there is a feature called Visual Upgrade that gives you an option to switch between SharePoint 2007 look and feel or the SharePoint 2010 view.  Note that if you have customized themes on the old site, you must re-create the new theme on the new site before you can switch.  To switch over to the new SharePoint 2010 look, do this:          

• Login as Site Owner and select Site Actions > Visual Upgrade.
  

• Select Update the user interface. Click OK.
  

 Here is the SharePoint 2010 look and feel:


Notes:

• The database attach method works with both SharePoint 2010 Foundation and Server.
• Limitations of the export/import method are:
  • You cannot save a workflow, alerts, features, solutions, or Recycle-Bin state by using the export operation.
  • Stsadm only supports moving entire Web sites (SPWeb instances). You are not able to export selected items or lists.
  • You cannot retain object globally unique identifiers (GUIDs) when you migrate site objects. New identifiers are added at the migration target.  

Main Difference of SharePoint Migration( 2007 to 2010 and 2010 to 2013)

Instead, you attach a 2010 content database to the 2013 farm. You have the option of retaining the content database as a 2010 content database and to perform what is called a “deferred site collection upgrade.” In essence, this means that the 2010 site collection continues to be a 2010 site collection, just running on a 2013 farm. This is very different than the “visual upgrade” from 2007 to 2010. When you upgraded from 2007 to 2010, the site was upgraded, which meant you had to ensure compatibility. But a master page and other trickery made the site retain the appearance of a 2007 site. In 2013, that option no longer exists. Instead, the 2013 farm retains the 2010 “14 Hive”—with all of its features, site definitions, etc.

So, in theory, all of your 2010 sites will work perfectly well, customization included, in 2013. When you perform a deferred site collection upgrade, you are conceptually “flipping the switch” so that the site collection now runs against the “15 hive”. That is when compatibility might matter.

So, keeping this very high level, the theory is that you could upgrade your farm this weekend to 2013, and your users would be none the wiser. That’s certainly the type of platform upgrade path that Microsoft wants and needs in the cloud (Office 365).

We will see, shortly, just how well it works in the real world. But my guess is we will be much closer to a happy story than to an unhappy story. And, obviously, you will want to test the upgrade process before you actually perform it. But the bottom line is that we’re close to a point where upgrading the platform will become a non-issue, a very minor issue, or at least not a multi-month, insane project.

Because you are likely going to find that you can upgrade smoothly, you can move collaboration workloads from 2010 to 2013 quickly, or implement plans for 2010 in 2013 instead, as 2013 still supports 2010-style customization, workflows, etc.

You can learn more about upgrading to SharePoint 2013 in the Reference Link. As with all other upgrades, there’s no direct upgrade path from 2007 or earlier versions of SharePoint to 2013. You either have to go through 2010 on the way, or use a third party tool. And—knowing that you probably did things in 2007 that you would not choose to do the same way in 2013—I’d strongly recommend a good third party migration tool.

This should give you plenty to chew on for the next few days. Next week, we’ll look at some of the reasons people give me for not moving to SharePoint 2013, including the infamous “we always wait for Service Pack 1” argument. So this discussion is definitely not finished. See you next week!

SharePoint 2010 to 2013 Upgrade Overview

To upgrade from SharePoint 2010 Products to SharePoint 2013, you use the database-attach method to upgrade. In the database-attach method, you first create and configure a SharePoint 2013 farm. Then you copy the content and service application databases from the SharePoint 2010 Products farm, and then attach and upgrade the databases. This upgrades the data to the new version. Site owners can then upgrade individual site collections.

Figure: The sequence of upgrade stages

Note: This article applies to both SharePoint Foundation 2013 and SharePoint Server 2013, except for information about how to upgrade My Sites and specific service applications that are only in SharePoint Server 2013.

Create the SharePoint 2013 farm

The first stage in the upgrade process creates the new SharePoint 2013 farm:

1. A server farm administrator installs SharePoint 2013 to a new farm. The administrator configures farm settings and tests the environment.
2. A server farm administrator sets the SharePoint 2010 Products farm to read-only so that users can continue to access the old farm while upgrade is in progress on the new farm.
   Figure: Create new farm, set old farm to read-only
   

Copy the SharePoint 2010 Products databases

The second stage in the upgrade process copies the databases to the new environment. You use SQL Server Management Studio for these tasks.

1. With the farm and databases in read-only mode, a server farm administrator backs up the content and service application databases from the SQL Server instance on the SharePoint 2010 Products farm.
2. The server farm administrator restores a copy of the databases to the SQL Server instance on the SharePoint 2013 farm and sets the databases to read-write on the new farm.
   Figure: Use SQL Server tools to copy databases
   

Upgrade SharePoint 2010 Products databases and service applications

The third stage in the upgrade process upgrades the databases and service applications.

1. A server farm administrator configures the service applications for the new farm. The following service applications have databases that you can upgrade during this process:
   • SharePoint Server 2010 and SharePoint Foundation 2010
     • Business Data Connectivity service application
   • SharePoint Server 2010 only
     • Managed Metadata service application
     • PerformancePoint Services service application
     • Search service application
     • Secure Store Service application
     • User Profile service application
2. A server farm administrator creates a web application on the SharePoint 2013 farm for each web application on the SharePoint 2010 Products farm.
   Figure: Create web applications for upgrade
   
3. A server farm administrator installs all server-side customizations.
   Figure: Copy customizations to the new farm
   
4. A server farm administrator then attaches the content databases to the new farm and upgrades the content databases for those web applications.
   Figure: Upgrade the databases by using Windows PowerShell
   
5. A server farm administrator confirms that the upgrade is successful.

Upgrade SharePoint 2010 Products site collections

The final stage in the upgrade process is to upgrade the site collections. In SharePoint 2013, site owners are in charge of upgrading their sites. The upgrade process for My Sites is slightly different from for other types of site collections.

Upgrade My Sites

Note: This section applies to SharePoint Server 2013 only.

A server farm administrator upgrades the My Site host and then individual users can upgrade their My Sites or the farm administrator can upgrade them by using Windows PowerShell. The following illustration shows four stages for the My Site host and My Sites during the upgrade process.

Figure: Stages in upgrading My Sites

1. The My Site host has not been upgraded. My Sites cannot be upgraded yet.
2. A server farm administrator has upgraded the My Site host. No My Sites have been upgraded.
3. Some users have upgraded their My Sites.
4. All My Sites have been upgraded.

Note: A server farm administrator can choose to force an upgrade of My Sites without waiting for users to upgrade them.

Upgrade other SharePoint 2010 Products site collections

Owners of all other site collections can start to upgrade their sites as soon as they see a notification on their site's home page that the new version is available. The following illustration shows four stages for a site collection during the upgrade process.

Stages in upgrading site collections

1. The site owner runs the site collection health checks to determine readiness for upgrade. The site owner addresses issues before they continue with the next step.
2. Optionally, the site owner requests an upgrade evaluation site collection. A timer job runs to create the site collection and the site owner receives an email message when the evaluation site collection is ready. The site owner previews the new user interface. After several days or weeks, the evaluation site collection expires and is deleted by a timer job.
   A server farm administrator can determine the length of time before expiration.
3. When the site owner is ready, the site owner starts the upgrade process. The site collection health checks are run again automatically. The site owner must address issues before upgrading. If health checks return no issues, the upgrade starts.
4. When upgrade is complete, the site owner sees the Upgrade Status page that contains the status and a link to the upgrade logs. The site owner reviews the site to make sure that everything works correctly.

Java Script For Page Referesh

You can also use JavaScript to refresh the page automatically after a given time period. Following is the example which would refresh this page after every 5 seconds. You can change this time as per your requirement.

<html> <head> <script type="text/JavaScript"> <!-- function AutoRefresh( t ) { setTimeout("location.reload(true);", t); } // --> </script> </head> <body onload="JavaScript:AutoRefresh(5000);"> <p>This page will refresh every 5 seconds.</p> </body> </html>

Here setTimeout() is a built-in JavaScript function which can be used to execute another function after a given time interval.

To understand it in better way you can Try it yourself.

Sharepoint - The search request was unable to connect to the Search Service.

Follow the below methods:

Central Admin -> Service Applications ->Manage service applications make sure your search service application is running with a proxy just below it. If not, likely because you did a backup and the proxy requires a second backup, from the ribbon select New -> Search Service Application.

Once created successfully go to CA -> Web Applications -> Manage web applications. Highlight the sharepoint port 80 site and select Service Connections. Make sure your new proxy is selected.

Then under CA -> Application Mgmt -> Manage services on server select Sharepoint Server Search select the new service you setup and make sure the topology looks ok. Then schedule and start a new Full crawl. All set.

AND

Don't forget to add the pdf file type if you've set that up under the old search app before.
-----------------------------------------------------------------------------------------------------------

Central Admin > Application Management > Office SharePoint Server Shared Services > Create or Configure this farm’s shared services
Shared Services Provider (drop down) > Edit Properties
Edit Shared Services Provider > Index Server: Verify the index server is set

Single Server Farm

On the MOSS 2007 server:

Start > Run > CMD > stsadm.exe -o osearch -action stop
Start > Run > CMD > stsadm.exe -o osearch -action start -role query index

Multiple Server Farm

On the MOSS 2007 Front End Web/Query server:

Start > Run > CMD > stsadm.exe -o osearch -action stop

On the MOSS 2007 Index server:

Start > Run > CMD > stsadm.exe -o osearch -action stop

On the MOSS 2007 Index server:

Start > Run > CMD > stsadm.exe -o osearch -action start -role index

On the MOSS 2007 Front End Web/Query server:

Start > Run > CMD > stsadm.exe -o osearch -action start -role query

Go to Central Admin ->Operations ->Topologies and services ->Services on server
Click “Office SharePoint Server Search”
Make sure the user has sufficient permission to access database.
Note: If your Search query and indexing server are same then set both options “Use this server for indexing content” and “Use this server for serving search queries” to true.

What is page redirection ?

When you click a URL to reach to a page X but internally you are directed to another page Y that simply happens because of page re-direction. This concept is different from JavaScript Page Refresh.
There could be various reasons why you would like to redirect from original page. I'm listing down few of the reasons:

• You did not like the name of your domain and you are moving to a new one. Same time you want to direct your all visitors to new site. In such case you can maintain your old domain but put a single page with a page re-direction so that your all old domain visitors can come to your new domain.
• You have build-up various pages based on browser versions or their names or may be based on different countries, then instead of using your server side page redirection you can use client side page redirection to land your users on appropriate page.
• The Search Engines may have already indexed your pages. But while moving to another domain then you would not like to lose your visitors coming through search engines. So you can use client side page redirection. But keep in mind this should not be done to make search engine a fool otherwise this could get your web site banned.

How Page Re-direction works ?

Example 1:

This is very simple to do a page redirect using JavaScript at client side. To redirect your site visitors to a new page, you just need to add a line in your head section as follows:

<head> <script type="text/javascript"> <!-- window.location="http://www.newlocation.com"; //--> </script> </head>

To understand it in better way you can Try it yourself.

Example 2:

You can show an appropriate message to your site visitors before redirecting them to a new page. This would need a bit time delay to load a new page. Following is the simple example to implement the same:

<head> <script type="text/javascript"> <!-- function Redirect() { window.location="http://www.newlocation.com"; } document.write("You will be redirected to main page in 10 sec."); setTimeout('Redirect()', 10000); //--> </script> </head>

Here setTimeout() is a built-in JavaScript function which can be used to execute another function after a given time interval.
To understand it in better way you can Try it yourself.

Example 3:

Following is the example to redirect site visitors on different pages based on their browsers :

<head> <script type="text/javascript"> <!-- var browsername=navigator.appName; if( browsername == "Netscape" ) { window.location="http://www.location.com/ns.htm"; } else if ( browsername =="Microsoft Internet Explorer") { window.location="http://www.location.com/ie.htm"; } else { window.location="http://www.location.com/other.htm"; } //--> </script> </head>

---

Keep on prompting for credential

To save your SharePoint password: Add the SharePoint site to the Local Intranet Zone in Internet Explorer. To do this, go to Tools > Internet Options > Security. In Local Intranet, click the Sites button and then Advanced. Add your SharePoint URL. Click Ok. Go to Start > Run and type in "control keymgr.dll’" to open the Windows key manager. Add <your_sharepoint_site_address> with your SharePoint site login credentials. If this entry already exists, edit it to have your login credentials.  For Vista users, when using the key manager, make sure you select "A Web site or Program credentials" for the type of password, and if prompted to change your password, say "no" (unless you want to change your password). Enter your password and click OK. Reboot the computer. If you are missing the Add button, you may want to modify Windows Registry to be able to save the password. Note that for editing Windows Registry, administrator rights are required. Editing Windows Registry is not safe and you will perform it at your own risk. In Windows, go to Start > Run and enter "regedit". Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\. Find the DisableDomainCreds entry. A value of 1 (enabled) will prevent you from saving new credentials. Change the value to 0 and reboot. Now you should have the Add button available. Note that 0 is the default value. Also check the LmCompatibilityLevel entry. It should be set to 3, which is the default value. If you have another value, change it to 3. If it does not work with 3, then also try it with 2. Reboot the computer to apply changes.

SharePoint 2010 User Information Update

One of my clients recently had an issue where a particularly high profile user (CEO) had their title spelled incorrectly in Active Directory; unfortunately the error wasn’t noticed right away and now, despite changing the information in Active Directory, SharePoint was still showing the wrong title in the People Picker when granting the user rights to a Site Collection. Fortunately I had a partial PowerShell script to fix the issue and just needed to only slightly modify it – you can see the original script on pages 299 and 300 of my book. So before I show the modified script it’s first important to understand the problem and why I needed to use a script and why what I had in the book is somewhat incomplete.

Whenever you grant a user rights to a Site Collection or when that user creates/updates/deletes any item within a Site Collection, an entry for the user will be added to a hidden user information list, if not already there. This “User Information List” is located at http://<SiteCollectionUrl>/_catalogs/users/detail.aspx:

By looking at this list you can see that several key pieces of information are stored here – unfortunately, when you change this information in Active Directory the information stored here is not updated (even after running a full or incremental import via UPS). To complicate matters there is no way to edit the information via the browser, thus the need for a PowerShell script. If you click the user’s name you’ll see the additional properties, including an “Edit Item” option, however, the edit dialog is simply a read-only display of the username, helpful right?:

So let’s first consider the scenario that my book addresses and assume that a user had had their name and/or email address changed. To accommodate this scenario we simply use the Set-SPUser cmdlet along with the -SyncFromADparameter. The following script is taken directly from my book and simply iterates through all Site Collections and calls theSet-SPUser cmdlet for the provided user:

function Sync-SPUser([string]$userName) {

  Get-SPSite -Limit All | foreach {

    $web = $_.RootWeb

    if ($_.WebApplication.UseClaimsAuthentication) {

      $claim = New-SPClaimsPrincipal $userName -IdentityType WindowsSamAccountName

      $user = $web | Get-SPUser -Identity $claim -ErrorAction SilentlyContinue

    } else {

      $user = $web | Get-SPUser -Identity $userName -ErrorAction SilentlyContinue

    }

    if ($user -ne $null) {

      $web | Set-SPUser -Identity $user -SyncFromAD

    }

    $web.Dispose()

    $_.Dispose()

  }

}

Before I make any changes to demonstrate this script and the modifications we’ll make to it, let’s first see how my user is currently set in the Site Collection:

And as shown in the People Picker:

Note the “Name”/”Display Name”, “Work e-mail”/”E-Mail”, and “Title” fields.

Now I’ll change these values in Active Directory (make the “p” in my last name capitalized, change the title, and set the email) and then run the script (I saved the script as Sync-SPUser.ps1):

(Note that lowercase “p” is the correct spelling for my name, just in case you were wondering ). Now if we look at the user details in the Site Collection and the People Picker we should see the following:

Notice that the the “Name” / “Display Name” and “Work e-mail” / “E-Mail” fields were updated but not the “Title” field. This is because the Set-SPUser cmdlet and -SyncFromAD parameter only updates these two fields. So how do you update the remaining fields? We simply need to add some code to our function which will grab the SPListItem corresponding to the user from the hidden “User Information List” and then update the corresponding fields manually. The following modified script does this for the “Title” field (note that I’ve changed the function signature to take the title in as a parameter):

function Sync-SPUser([string]$userName, [string]$title) {

  Get-SPSite -Limit All | foreach {

    $web = $_.RootWeb

    if ($_.WebApplication.UseClaimsAuthentication) {

      $claim = New-SPClaimsPrincipal $userName -IdentityType WindowsSamAccountName

      $user = $web | Get-SPUser -Identity $claim -ErrorAction SilentlyContinue

    } else {

      $user = $web | Get-SPUser -Identity $userName -ErrorAction SilentlyContinue

    }

    if ($user -ne $null) {

      $web | Set-SPUser -Identity $user -SyncFromAD

      $list = $web.Lists["User Information List"]

      $query = New-Object Microsoft.SharePoint.SPQuery

      $query.Query = "<Where><Eq><FieldRef Name='Name'/><Value         Type='Text'>$userName</Value></Eq></Where>"

      foreach ($item in $list.GetItems($query)) {$item["JobTitle"] = $title

      $item.SystemUpdate()

      }

    }

    $web.Dispose()

    $_.Dispose()

  }

}

The changes to the original function have been highlighted. Note that the internal field name for the “Title” field is “JobTitle” and that is what we are using to set the Title. Now if we run this modified script we should see the Title field updated:

Okay, so what about the other fields (Department, Mobile Number, etc.)? You can see what fields are available to edit by running the following:

In the preceding example I’m grabbing a specific item (in this case the item corresponding to my user) so that I can see the internal field names in context with the data stored by the field – this helps to make sure that I grab the correct field name (i.e., “JobTitle” vs. “Title”). Now you can just add additional fields to update right before the call to SystemUpdate() – simply follow the pattern established for the title field.

So, add this guy to your script library and you’ll be good to go next time someone changes their name, email, or job title.