Friday, September 11, 2015

PowerShell Scripts do all the Things

http://get-spscripts.com/2010/09/changing-master-page-on-sharepoint.html

Changing the master page on SharePoint sites with PowerShell

On SharePoint Server 2010 publishing sites, you can change the name of the master page from the browser UI by going to Site Settings > Master page, under the “Look and Feel” section. However, as this option does not exist in the administration UI on team sites, each site in the site collection will retain a copy of its own master page by default, and it is not possible to change the name or location of it from the browser. For example, if you had one top level team site and five sub-sites, that is six separate master pages to manage for a relatively small structure.
One approach you may want to take is to store a central master page on the root site of the site collection and use PowerShell to change the master page setting for all sites in the site collection, pointing to the new name and location. To do this, first upload your new master page to the master page gallery on the root site of the site collection by going to Site Settings > Master pages under the “Galleries” section, clicking on the Documents tab, and uploading the new custom master page to the library:

if you want to change the master page setting for just one site, then use the script below:

$web = Get-SPWeb siteurl
$web.MasterUrl = "masterpagerelativeurl"
$web.Update()
$web.Dispose()

For the example site pictured above, the script would be as follows:

$web = Get-SPWeb http://portal/sites/collaboration
$web.MasterUrl = "/sites/collaboration/_catalogs/masterpage/custom.master"
$web.Update()
$web.Dispose()

Refreshing the root site in the browser will now show the new master page design, but all sub-sites will still show the old master page design – this is because they are each using a master page stored on their respective site. To change the master page setting for all sites in a site collection, use the following script:

$site = Get-SPSite http://portal/sites/collaboration
$site | Get-SPWeb -limit all | ForEach-Object { $_.MasterUrl = "/sites/collaboration/_catalogs/masterpage/custom.master";$_.Update() }
$site.Dispose()

Note that this will only change existing sites and will not set a custom master page for any new sites created. To update new sites, you will need to either run the script every time a new site is created, or use an alternative approach such as a feature receiver/stapler or Web provisioning event receiver to automatically set the new master page on site creation.
If you want to revert all team sites in the site collection back to using their own default master page again, then use the following script:

$site = Get-SPSite http://portal/sites/collaboration
$site | Get-SPWeb -limit all | ForEach-Object { $_.MasterUrl = $_.ServerRelativeUrl + "/_catalogs/masterpage/v4.master";$_.Update() }
$site.Dispose()

Download Files/Images from SharePoint Libraries using PowerShell

I consigned a task to backup all files inside different document libraries of a SharePoint site on hard disk. We need to reorganize the entire site and this site comprises so many document libraries. So downloading documents one by one is a gigantic task as the site has gigs of docs. Alternative option is to open libraries in explorer and start copying them to a place, but this methodology has so many limitations e.g. network speed, installation of office components, much time required etc.

I want to get this job done hastily. So for a moment I thought of Power Shell. I want to give it a try and trust me by using this I was able to download gigs of documents within minute. Below is the code snippet for your reference:

######################## Start Variables ########################
######################## Download Files Script######################
$destination = $args[0]
$webUrl = $args[1]

##############################################################
# Replace actual document libraries name with DocLib1, 2, 3 etc.
$listUrls=”DocLib1″,”DocLib2″,”DocLib3″,”DocLib4″,”DocLib5″

$web = Get-SPWeb -Identity $webUrl

foreach($listUrl in $listUrls)
{
$list = $web.GetList($webUrl+”/”+$listUrl)

function ProcessFolder {
    param($folderUrl)
    $folder = $web.GetFolder($folderUrl)
    foreach ($file in $folder.Files) {
        #Ensure destination directory
        $destinationfolder = $destination + “/” + $folder.Url
        if (!(Test-Path -path $destinationfolder))
        {
            $dest = New-Item $destinationfolder -type directory
        }
        #Download file
        $binary = $file.OpenBinary()
        $stream = New-Object System.IO.FileStream($destinationfolder + “/” + $file.Name), Create
        $writer = New-Object System.IO.BinaryWriter($stream)
        $writer.write($binary)
        $writer.Close()
        }
}

#Download root files
ProcessFolder($list.RootFolder.Url)
#Download files in folders
foreach ($folder in $list.Folders) {
ProcessFolder($folder.Url)
}}

Copy this to a notepad file and save with extension .ps1 E.g.DownloadFiles.ps1

Open SharePoint Management Shell 2010; navigate to the path of script. Provide destination path as argument 1 and site URL as argument 2 as shown below.

.\DownloadFiles.ps1 “d:\documents” http://mySite

*This will create separate folders for each document library with library name.

Accessing mixed authentication web app with Client Object Model and Web Serices

I have mixed authentication web app in SharePoint 2010: both Windows (NTLM) and Forms based.
When I tried to access it using Client Object Model with my NTLM credentials I got 401 (Unauthorized) exception. I googled and found this solution


...
clientContext.ExecutingWebRequest += new EventHandler(clientContext_ExecutingWebRequest);
...
}

static void clientContext_ExecutingWebRequest(object sender, WebRequestEventArgs e)
{
e.WebRequestExecutor.WebRequest.Headers.Add("X-FORMS_BASED_AUTH_ACCEPTED", "f");
}

This works well for me.

Then when I tried to access same site using Lists.asmx web service with same NTLM credentials I got exactly same exception.
I added this method to the Web Service wrapper class (it's in Web References > ListWebService > Reference.map > Reference.cs in my case)


protected override System.Net.WebRequest GetWebRequest(Uri uri)
{
System.Net.WebRequest wr = base.GetWebRequest(uri);
wr.Headers.Add("X-FORMS_BASED_AUTH_ACCEPTED", "f");
return wr;
}

That solved the issue as well.

The query cannot be run for the following DataObject: GetCommonManager

I got that message when I previewed an InfoPath form (SharePoint Server 2010, InfoPath 2010):

The query cannot be run for the following DataObject: GetCommonManager
InfoPath cannot run the specified query.
The SOAP response indicates that an error occurred on the server:
Server was unable to process request. ---> Object reference not set to an instance of an object.

I knew that new User Profile Service Application had been created and it used to work with old one without issues. The UserProfileService web service was healthy and calls for GetUserProfileByName were proceeded well. It just stuck with GetCommonManager call.

After some investigation I found My Site host was not defined in that brand new User Profile Service Application. When I defined it My Site Settings for the application GetCommonManager started working again.

Hope that helps save time someone.

Sharepoint Export Import Details | For Export only

Export: For Exporting Share point data from one farm to another, Share point provides a class SPExportSettings which contains various settings to export data from source server in the form of .cab files. Some of the important settings are described below .

1. AutoGenerateDataFileName : Gets and sets the value that indicates whether a file name for the content migration package should be automatically generated.

2. ExportChangeToken : Gets or sets the change token to use when exporting incremental changes based on changes since the last export.

a. Understanding Change Tokens

Share point creates change log if we have made any changes in SPObject and is stored in the EventCache table of the content database. This table stores the information about all content changes in the content database. Each entry in the Change log contains the following information:

· A sequential number (Id) identifying the row in the event cache table

· The timestamp (EventTime) when the change has happened

· The type of the object (ObjectType) that has changed

· Identification (one or multiple IDs) of the object that was changed

· URL to the object that was changed (if the object has a URL)

· The type of modification (EventType)

b. About the Change Token

Each time the change log is queried for changes, it returns the changes together with a Change Token which corresponds to a database entry up to which the querying application has been synchronized. This change token is of the format Int1; Int2; Guid; Time; Int3.

Example: 1;1;df6828cf-c303-453e-9eb6-e733f85611ac;633782543234470000;1510 Where,

· Int1: Contains version information for the change token. Currently this value is always 1.

· Int2: The scope the change token has been requested for. For example, if you ask for changes in the site collection this value will have the scope "Site". If you request changes for a sub site, it will contain the scope "Web". See the following table for possible values. Related to content deployment and the underlying API, this value is always 1 as content deployment always generates a change token with a scope of the whole site collection.

· Guid: Guid of the object the change token belongs to. If the change token was requested for a site collection this will be the Id of the SPSite object.

· Time: Timestamp (in ticks) of the change the token belongs to.

· Int3: change number in the event cache table the change belongs to.

c. Code To Get change Token

using (SPSite siteCollection = new SPSite("http://localhost"))

{

using (SPWeb webSite = siteCollection.RootWeb)

{

// Create a change token.

DateTime startTime = DateTime.UtcNow.AddDays(-60);//default 60 days

SPChangeToken startToken = new SPChangeToken(SPChangeCollection.CollectionScope.Web, webSite.ID, startTime);//Create token by itself by passing web Id

// Retrieve the first batch of changes.

SPChangeCollection changes = webSite.GetChanges(startToken);

// Get another batch.

startToken = changes.LastChangeToken;

changes = webSite.GetChanges(startToken);

}

3. ExportMethod :This property has two possible values

a. Full Export : After setting this flag to ExportMethod property Sharepoint Exports all the objects from source site collection.

b. Incremental Export : After settings this flag to ExportMethod property Sharepoint export only change objects calculated from ExportChangeToken.

4. IncludeSecurity : Determines whether site security groups and the group membership information is exported or imported, this property has three possible values

a. All : To migrate user and group information to include during an export or import operation.

b. None : No User Information migrated.

c. Wss Only : Only role assignments such as out of the box roles like Web Designer, or any custom roles that extend from the out of the box role.

5. IncludeVersions : Determines what content is selected for export based on version information,

a. All

b. Current Version

c. Last Major

d. Last Major And minor

6. SiteUrl : absolute URL of a source or destination Web site.

7. ExcludeDependencies : whether to exclude dependencies from the export package when exporting objects of type SPFile or SPListItem.

Sample Code :

private void Export(string siteURL)

{

Microsoft.SharePoint.Deployment.SPExportSettings exportSettings = new Microsoft.SharePoint.Deployment.SPExportSettings();

exportSettings.AutoGenerateDataFileName = true;

exportSettings.ExportMethod = Microsoft.SharePoint.Deployment.SPExportMethodType.ExportChanges;

exportSettings.SiteUrl = siteURL;

exportSettings.IncludeSecurity = Microsoft.SharePoint.Deployment.SPIncludeSecurity.All;

exportSettings.IncludeVersions = Microsoft.SharePoint.Deployment.SPIncludeVersions.LastMajorAndMinor;

using (SPSite siteCollection = new SPSite(siteURL))

{

using (SPWeb webSite = siteCollection.RootWeb)

{

SPChangeToken startToken = new SPChangeToken(SPChangeCollection.CollectionScope.Web, webSite.ID, startTime);

// Retrieve the first batch of changes.

SPChangeCollection changes = webSite.GetChanges(startToken);

exportSettings.ExportChangeToken = changes.LastChangeToken.ToString();

}

Microsoft.SharePoint.Deployment.SPExport export = new Microsoft.SharePoint.Deployment.SPExport(exportSettings);

export.Run();

}

Optimizing SharePoint 2013 websites for mobile devices

The mobile market is growing continuously, and in the near future, more mobile devices than desktop computers will be used to surf the web. To ensure a user-friendly experience, we must optimize Internet websites for presenting content across the different devices. SharePoint 2013 offers a number of options for optimizing public-facing websites for mobile devices. Depending on your requirements, you can choose one or a combination of several options.

In the last few years, the use of mobile devices to surf the web has increased significantly. According to some researchers, by 2015, more mobile devices than desktop computers will be used to access the web. Mobile devices come in different sizes and capabilities. And since the desktop experience just isn’t good for mobile users, what are the options for improving the experience of mobile users on your website?

Improving the user experience across devices

Optimizing the user experience of a website across different devices is a complex process. Not only do you have to take into account the screen resolution of each device, but you also need to consider its capabilities (such as touch or pointer-based) and device size (1024x768 might be clearly readable for everyone on a 20-inch monitor but might result in a very bad experience on a 5-inch screen).

When you are planning improvements to the user experience of your website on mobile devices, there is no silver bullet approach. You have to research who your users are, which devices they use, and what they are trying to achieve on your website. You also have to have clear goals for what purpose your website serves and how it should guide your visitors in the process of becoming your customers.

You have several options for improving the user experience of a public-facing website. Which one you choose depends on the different factors that apply to your scenario.

Mobile websites

In the past, when the web technology wasn’t as sophisticated as it is nowadays, it was a common practice to provide mobile users with a separate mobile website to optimize their experience. Being hosted on a separated URL, such as http://m.contoso.com, the mobile site would have a user experience optimized for mobile devices. In some scenarios, organizations would even go a step further and optimize the copy on the mobile website. When a user navigated to the website using a mobile device, the main website would detect the use of a mobile device and automatically redirect the visitor to the mobile version.

It’s not that hard to imagine that building and maintaining two different sites is not only costly but also time consuming. Every update has to be done separately. Even then, with the diversity of today’s mobile devices, the questions remain whether a single mobile website would suffice and whether you wouldn’t need more websites to reach the whole spectrum of your customers.

Being able to reuse the content across the main and mobile websites simplifies the content management process. But the need to separately maintain the functionality of both websites makes it hard to justify this approach in most scenarios.

Mobile apps

One of the recent developments of the mobile market is the increased popularity of companion apps. By using the native capabilities of specific devices, you can build rich mobile apps to support different use cases. There is no better user experience on a mobile device than the native one offered by the device itself. For more information, see Build mobile apps for SharePoint 2013.

But is it realistic to build separate apps for all the different scenarios and for all the different mobile devices used to navigate the website? Although mobile apps are of great value for supporting specific use cases, there is still the need to access the information on the website from a mobile device in a user-friendly way.

Responsive web design

Instead of building separate mobile sites for mobile devices, what if we could have one website that automatically adapts itself to the particular device?

Responsive web design is a concept based on the ability to separate the design from the content on a website. Using the CSS media queries capability implemented in all modern browsers, and based on the screen dimensions of the specific device, you can load different style sheets to ensure that the website is presented in a user-friendly manner. And because CSS has its limitations, you can use JavaScript to further optimize the interface and interaction of a website on mobile devices. For more information, see Implementing your responsive designs on SharePoint 2013.

From the search engine optimization (SEO) perspective, responsive web design is the recommended way to optimize public-facing websites for mobile devices. After all, since the same HTML is sent to every device, it’s sufficient for an Internet search engine to index the content once, and it can be sure that the search results will apply the search query on every device.

Implementing responsive web design on a public-facing website is relatively easy assuming you start planning for it from the beginning. The great advantage of responsive web design above other approaches is that you maintain your website once to support a variety of audiences, and the different experiences are future-proof as they depend on the devices’ dimensions rather than their identity.

The following figures show how the sample Contoso Electronics website is displayed on different devices using responsive web design. Figure 1 shows the screen shot taken on a desktop device.

Figure 1. The Contoso Electronics website displayed on a desktop device

Figure 2 shows how the Contoso Electronics website looks like on different mobile devices.

Figure 2. The Contoso Electronics website displayed on mobile devices

SharePoint 2013 device channels

One of the new capabilities of SharePoint 2013 is device channels. You can use device channels to optimize how a website is displayed on different devices. By defining different channels and associating different devices with them, you can use different master pages to optimize how the website is presented to the user. For more information, see How to: Create device channels in SharePoint 2013. Figure 5 shows a sample configuration of device channels for a public-facing website built with SharePoint 2013.

Figure 3. Device channels configured for a public-facing website built on SharePoint 2013

Whereas responsive web design uses a device’s screen size to determine the presentation layer, device channels in SharePoint 2013 use the identity of the browser on the particular device to decide which presentation style to use. Depending on how many different devices your site visitors use, managing the different devices and experiences can become complex. By using device channels, you get more flexibility in controlling the markup of your website for the different devices. Another benefit of using device channels is that you can serve different content to different devices, whereas the same content is served when using responsive web design. With device channels, you can apply additional optimizations to your website, such as resizing images and videos server-side using the renditions capability, which further improves the performance and user experience of your website. For more information, see How to: Manage image renditions in SharePoint 2013.

With all the different options at our disposal, which one should we use to get the best results?

Improving the user experience of a public-facing website in SharePoint 2013

First and foremost, it’s important to note that SharePoint 2013 supports all the methods mentioned above for improving user experience on mobile devices. Whether you’re looking at building a separate website for mobile users, supporting certain use cases with a mobile app, implementing responsive web design, or using device channels, it can all be implemented in your website on top of SharePoint 2013.

Not only does SharePoint 2013 not stand in your way, but it also supports you in implementing some of those improvements. For example, using the cross-site publishing capability, you can easily publish the centrally managed content on both the main and the mobile websites. With the Search REST API, you can have your content published in your mobile app, and if you’re looking at optimizing the presentation of your website across different devices, SharePoint 2013 offers plenty of features to help you.

With all these techniques at your disposal, it is up to you to decide which method, or combination of methods, is the best choice for what you’re trying to achieve. While you might be interested in supporting a particular complex process with a dedicated mobile app, it might still be of added value to ensure that everyone, regardless of their device, can access all the information on your website.

In most scenarios, it’s easy to choose whether or not the particular optimization technique offers added value. A slightly more difficult choice, partly due to the similarity of both methods, is whether you should use responsive web design or device channels to optimize the presentation of your website for mobile devices.

Responsive web design and device channels comparison

Responsive web design and the SharePoint 2013 device channels capability are similar in how they let you optimize a single website to be displayed in a user-friendly way on different devices. Despite this similarity, there are a few important differences between both approaches. Table 1 presents a comparison of the different properties of both approaches.

Device channels	Responsive web design
Device management	Property management
Different HTML for every channel	Same HTML for every device
More management (support for new devices)	Future proof (device size)
More flexibility	Limited by CSS support and capabilities
Custom Vary-By User Agent response header required	Preferred by Internet search engines

Table 1. Comparison of device channels and responsive web design

Applying user experience

First of all, there is a difference in how both approaches determine which user experience should be applied for the particular user. Responsive web design uses the size of the screen to determine how the content should be laid out in the browser’s window. Device channels, on the other hand, use the identity of the browser to load the suitable channel.

While responsive web design can cause different experiences to be loaded depending on the size of the browser window, device channels will always load the same experience for the same device regardless of the browser window size. Using device channels can have great advantages, for example, from the troubleshooting point of view where the user and the helpdesk employee would see the same interface despite the possible differences in their screen resolutions or browser window sizes.

Page markup

Another difference between device channels and responsive web design is how the page contents are served. Responsive web design changes only the presentation layer of the website. Although you can hide some pieces of the page in the browser using CSS, they are still present in the website’s code and therefore loaded. When using device channels, you can use different master pages to ensure that only the relevant markup is served to users. Additionally, you can use the device channel panels to further control the content elements loaded on specific pages.

Although device channels allow for better control of the rendered HTML and therefore optimized performance of the website, more effort is required to ensure that Internet search engines will properly deal with all the different versions of the website presented to different devices. You can achieve this by using the Vary-By User Agent response header, but it has to be done manually.

Future-proofness

Responsive web design uses the size of the browser window to distinguish between the different experiences. This is a robust approach, and the chances are low that a new device will appear on the market that has a poor user experience despite the configured breakpoints. One reason for that might be related to some specific capabilities of such devices, but again, chances of this are very rare.

SharePoint 2013 device channels are based on the identity of the browser used to open the website. There are two challenges with this approach. First of all, in some situations it might be impossible to distinguish between the same browser installed on the same operating system but on two devices with distinct capabilities. Second, if a new device appears on the market, you would have to verify that this device is assigned to the right device channel on your website.

Choosing the right approach for optimizing the user experience

Although responsive web design and device channels are very similar, their capabilities differ and they have different impact when used for optimizing a website for mobile devices. Due to their similarities and their own strength, choosing between the two approaches is often difficult. Why not combine both approaches to get the best of what they offer?

Combining responsive web design and device channels

An interesting scenario worth considering is to combine responsive web design and SharePoint 2013 device channels to benefit from the strengths of both approaches.

When combining responsive web design and device channels, you could use responsive web design to create the baseline cross-device experience. Depending on your design for the different breakpoints, using responsive web design could be good for the 80%, or maybe even 90%, of the optimizations. The remainder—whether they’re caused by how the web design changes between the breakpoints or by the capabilities of the different devices that should be supported—could be covered by device channels and device channel panels.

By using responsive web design to build the baseline for the cross-browser experience, we benefit from its future-proofness and robustness. For the specific exceptions, we can benefit from the granular control that SharePoint device channels offer us.

Deprecation of Custom Code in Sandboxed Solutions

Our bad. We’ve been guilty of sending mixed messages about the status of sandboxed solutions in SharePoint development. We’d like to clarify that now.

While developing sandboxed solutions that contain only declarative markup and JavaScript -- which we call no-code sandboxed solutions (NCSS) -- is still viable, we have deprecated the use of custom managed code within the sandboxed solution. We have introduced the new SharePoint app model as a replacement to those scenarios that required the use of managed code. The app model decouples the SharePoint core product from the app runtime, and this enables much more flexibility and gives you the ability to run the code in the environment of your choice. We realize that our customers have made investments in coded sandboxed solutions and we will phase them out responsibly. Existing coded sandboxed solutions will continue to work in on-premises SharePoint farms for the foreseeable future. Given the dynamic nature of online services, we will determine support needs for coded sandboxed solutions in SharePoint Online based on customer demand. NCSSs continue to be supported. All future investments will go to making the new SharePoint app model richer and more powerful. Accordingly, we recommend that all new development should use the new app model whenever possible. In scenarios where you have to develop a farm solution or coded sandboxed solution, we recommend that you design it so that it can easily evolve toward a more loosely coupled development model.