You have an old SharePoint 2010 site and you need to copy its content to another SharePoint farm. The site is heavily customized and moving it using traditional methods (backup/restore, export/import, save site as a template) are not going to work well. Plus you only want content – no need to bring in all of that custom branding baggage.

You can copy the content using PowerShell and two scripts shown below.

When administering a large SharePoint 2010 deployment, there are times when you may need to take an inventory of the user profiles in your profile store – perhaps to find users with a common property or characteristic, run some comparisons of your SharePoint profiles to Active Directory, or do some other administrative task.

Here’s a simple PowerShell script that enumerates all user profiles in the context of your SharePoint site and emits some of their properties, such as Display Name, AccountName, and workEmail.

Note: The account which will be executing this script needs to have Full Control access to the User Profile Service application. Follow these two steps:

As you may already know, SharePoint has a limitation on how long a page or file path (or URL) can be. This was an issue with SharePoint 2007 -Joel Oleson blogged about it back in June 2007:

“When storing files the structure and files (entire path including sites, folders, and file name) cannot add up to more than 260 characters or they will see an error message or form validation error with the explanation around the URL length. “

Official Microsoft documentation states that the same limit holds for SharePoint 2010:

“SPSite.MaxFullUrlLength Field

Represents the maximum number of characters that can be used in the absolute URL for a site collection.

Remarks
——————————————————————————–

The value of this constant is 260.

The MaxFullUrlLength field is static and cannot be called on an instance object. To call this field, use SPSite.MaxFullUrlLength.”

When you’re moving, upgrading, or migrating SharePoint sites, you may run into problems with URLs that are too long for SharePoint. You may see failures or errors when executing STSADM commands such as “stsadm -o export” or “stsadm -o import”.

I wrote a PowerShell script (see below) that allows you to take an inventory of all files in your web application and flag those files where the path (or URL) is longer than 260 characters.

Here’s how you can create and delete views in a SharePoint list or library using PowerShell (Is there anything that can’t be done through a PowerShell script?)

The script below creates a view called “TestView”. It expects three command-line arguments: site collection URL, the name of the view to create, and the list GUID. The view that’s created is an exact replica of the “All Items” view (you can certainly modify the code as needed). Here’s how you would call this script from the command line:

Finally, how do you find out the GUID of your list? It’s fairly straightforward – you just need to access the SPList.ID property of your list. Here’s a simple script that will output the GUIDs of all lists in your site collection:

For various SharePoint admin tasks, there are times when you need to execute an STSADM command from within a PowerShell script.

Before you can do that, you’ll need to tell PowerShell where to find STSADM executable. You can do that by adding the following line to your profile.ps1 file (usually located in C:\WINDOWS\system32\windowspowershell\v1.0 ):

Ok, this post isn’t even SharePoint-related, but since it took me 2 hours to figure out how to do this task (and since there’s little documentation on the subject), I’m going to post it here anyway. Maybe it’ll save someone hours of research and coding.

My task today was to programmatically refresh a Team Foundation Server list that was embedded into an Excel workbook. The process had to be completely automated. I found John Lawrence’s post and also the TFS team blog post. The problem with these solutions, they only work within an Excel VBA macro. I needed a way to open Excel, perform the TFS list refresh, and close it, without any user intervention.

Placing the macro into the workbook start-up didn’t work – apparently, the Team toolbar (and the accompanying Refresh button) don’t activate until AFTER all the start-up macros have run (which caused a problem for me).