SharePoint (and Project Server) Shenanigans

This is something I came across that is a little more light-hearted than usual.

Taken from Twitter Engineer Angus Croll’s blog.

Once upon a midnight dreary, while I struggled with JQuery,
Sighing softly, weak and weary, troubled by my daunting chore,
While I grappled with weak mapping, suddenly a function wrapping
formed a closure, gently trapping objects that had gone before.

Ah, distinctly I remember, it was while debugging Ember,
As each separate dying member left its host for ever more.
Eagerly I wished the morrow–vainly I had sought to borrow
(From my bookmarked trail of sorrow), APIs from Underscore.

There I sat engaged in guessing the meaning of each cursed expression,
Endless callbacks in procession; nameless functions, nothing more,
This and more I sat divining, strength and spirit fast declining,
Disclose the value we’re assigning! Tell me – tell me, I implore!

via Chris on SharePoint http://spchris.com/2013/05/if-edgar-allan-poe-wrote-javascript/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

You may encounter an exception when running certain SQL Server Reporting Services (SSRS) reports.

The exception message will generally say something along the lines of Operation is not valid due to the current state of the object.

You may encounter this either in reports with a large number of parameters, or in reports where the parameter counts are low but the parameters themselves are multiple choice and have a large number of items selected.

The cause of this is a security fix released by Microsoft under Security Bulletin MS11-100. The fix, among other things, limits the number of keys that ASP.NET applications can parse as part of a request; large numbers of keys could potentially allow a denial of service to occur.

Unfortunately the effect of this is that our large parameter set is blocked, causing the exception and presenting a nasty error to our end users.

Luckily there is a solution to this.

The trick is to add a section to your web.config inside the <appSettings /> section.

<appSettings>
	...
	<add key="aspnet:MaxHttpCollectionKeys" value="5000" />
	...
</appSettings>

The actual value used should reflect the number of keys you believe will be used, but 5000 is a reasonable starting point.

If you are using SSRS in native mode, the web.config file is located within the reporting services installation path, usually C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer.

If you are using SSRS in SharePoint integration mode, the modification needs to be made to the web.config of the application pool where you are running your reports. For this I would recommend that you create a solution that utilises the SPWebConfigModification class as part of a feature receiver, rather than making the changes directly. This will ensure that the change is made across your SharePoint farm simultaneously without the human error that could come from doing the change manually on multiple servers.

Note: In both cases, these modifications either require a restart of the reporting server or in the case of SharePoint a recycle of the Application Pool. This will result in short outages so you will want to schedule this as part of maintenance accordingly.

For more information I would recommend reading the relevant KB article.

via Chris on SharePoint http://spchris.com/2013/05/sql-server-reporting-services-reports-errors-when-large-numbers-of-parameters-are-selected-2/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

When working with SharePoint’s UI, it is often difficult to work out where in the URL structure you are.

You may for instance be working at the root of a site collection, but that itself may be several layers deep.

Take the following example.

You have a site collection for your company, but each team maintains its own site collection under the managed path (with wildcard inclusion) /teams.

Some of the team sites use a template that includes a master page that references an image gallery script. This gallery script has to load images out of a document library local to each team site.

The problem of course is determining the URL to the code and images, when they could be located at /teams/team-a/gallery images or /teams/team-b/gallery images

Of course in a server-side solution this is simple, SharePoint provides the handy shortcut of ~sitecollection. This works both directly in master pages:

<SharePoint:ScriptLink runat="server" Name="~sitecollection/Style Library/js/galleryscript.js" Language="javascript"/>

Or using a custom action within a SharePoint solution, sandboxed or otherwise:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<CustomAction
		ScriptSrc="~sitecollection/Style Library/js/galleryscript.js"
		Location="ScriptLink"
	/>
</Elements>

But how do we achieve the same within the front end itself?

Introducing _spPageContextInfo

The _spPageContextInfo object is a really wonderful little thing. It is added by the SPWebPartManager control, which is included in all of the out of the box master pages (including default.master and system.master) and I really strongly recommend is added to any custom master pages you create.

Because of it’s essentially omnipresent nature it makes using _spPageContextInfo a really simple matter of, well, using it.

It is a small object, containing only a few properties of the page, the site and the site collection it is part of. Here is a JSON representation of what it contains.

{
	alertsEnabled: true,
	allowSilverlightPrompt: "True",
	currentLanguage: 1033,
	pageItemId: 1,
	pageListId: "{6300d68a-4512-49f0-85b9-d3671855e31c}",
	siteServerRelativeUrl: "/teams/team-a",
	userId: 1,
	webLanguage: 1033,
	webServerRelativeUrl: "/teams/team-a/subsite",
	webUIVersion: 4
}

Here’s a brief explanation of the properties in it.

alertsEnabled

This one is simple, is SharePoint’s alerts email notification service enabled for the current web application. This maps to the SPWebApplication.AlertsEnabled property.

allowSilverlightPrompt

Will the user be prompted to download Silverlight if they do not already have it when they attempt to use Silverlight based UI elements. This maps to the SPWebApplication.AllowSilverlightPrompt property.

currentLanguage

This is the current locale being used by the user, if they have not changed it to a custom one, then this maps to the SPWeb.Language property.

pageItemId

This is the ID of the current page’s item within the document library containing it.

pageListId

This is the GUID of the document library containing the current page.

siteServerRelativeUrl

This is the path of the site collection, relative to the web application.

userId

This is the user’s ID for the current site collection.

webLanguage

This is the default language for the current web. This maps to the SPWeb.Language property.

webServerRelativeUrl

This is the path of the web, relative to the web application.

webUIVersion

This is the UI version of the current web, determining if the master page and components in use and available is compatible with SharePoint 2007 (3), SharePoint 2010 (4) or SharePoint 2013 (5)

Note: The actual properties available varies depending upon where you happen to be. For instance the pageItemId and pageListId properties do not exist within system pages, as they do not have IDs and do not live within document libraries.

That’s pretty cool, but how do we use it?

Well, as they are properties we can pretty much use them however we wish. Let’s take a look at a simple way of referencing files in our gallery images document library, for example referencing a logo to use on the homepage.

(function() {

	// The path to the image.
	var imagePath = '/gallery%20images/logo.jpg';

	// The relative URL is usually without the trailing /
	// however if we are on the root site collection then it
	// is simply / on its own and must be handled.
	if (_spPageContextInfo.siteServerRelativeUrl == '/') {
		imagePath = imagePath.substring(1);
	}

	// Build our full image path.
	imagePath = _spPageContextInfo.siteServerRelativeUrl + imagePath;

	// Finally set our image's source to the images path
	$('img#logoImage').attr('src', imagePath);

})();

Of course this is a rather contrived example, and you should probably be using the client side object model (CSOM) to pull items from a document library. However I hope it demonstrates how the object can be used.

A common use I use this for is is actually with the CSOM.

var ctx = new SP.ClientContext(_spPageContextInfo.webServerRelativeUrl);

I do it this way because I have had issues with concurrency when using the get_Current() method in SP.ClientContext when there is other code in use on pages that I do not have control over.

via Chris on SharePoint http://spchris.com/2013/05/managing-path-context-in-sharepoint/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

One of the many pieces of functionality added in SharePoint 2010 was the dialog window, this is a nice little control implemented in JavaScript that allows us to display a “lightbox” style dialog, containing either another page within our site or direct HTML.

This post will explain how to pass information back and forth between the page creating the dialog and the page displayed within that dialog.

Firstly lets take a look at the JavaScript on our calling page. This could be added through any of the normal methods of inserting JavaScript into a SharePoint page.

(function() {

	// Use jQuery to wait for the DOM to be ready
	$(document).ready(function(){

		// Use SharePoint's SOD (script on demand) to wait for SharePoint to be ready
		ExecuteOrDelayUntilScriptLoaded(function() {

			//Create an options object (valid options properties reference - http://msdn.microsoft.com/en-us/library/ff410058(v=office.14).aspx):
			var options = SP.UI.$create_DialogOptions();

			options.title = "My dialog";
			options.autoSize = true;
			options.url = "/pages/myPage.aspx";

			//arguments to pass in to dialog (standard anonymous object)

			options.args = {
				someKey: "Some Value",
				someOtherKey: "Some Other Value"
			}

			//callback to handle the result from the dialog, you process the result of your
			//dialog from the origin page.

			options.dialogReturnValueCallback = function(result, arguments) {
				if (result == SP.UI.DialogResult.OK) {

					// Our arguments parameter contains the arguments originally passed to the dialog, so we could
					// reference arguments.someOtherKey here for instance and it would contain the value "Some Other Value"

					SP.UI.Notify.addNotification("OK Button clicked");

				} else if (result == SP.UI.DialogResult.Cancel) {

					SP.UI.Notify.addNotification("Cancel button clicked");

				}
			}

			// Create the dialog with options.
			SP.UI.ModalDialog.showModalDialog(options);

		}, "SP.UI.Dialog.js");

	});

})();

As you can see, there are 3 major parts to this, the options object, the args object and the callback.

The options object is created using the SP.UI.$create_DialogOptions() factory, although I have seen people using an empty object without apparent issue.

Into this you set various options affecting the way the dialog is presented, such as title, size and the url to the page to be displayed. A list of available options is posted on MSDN.

The args object is actually a property of the options object, and can be any sort of JavaScript object, be it an anonymous object like in our example above, or a closure, or a data model or anything else you may wish to send. This object will be available within the page shown in your dialog.

The last part is the callback, this is also a property set against the options object, and is a callback method executed when the DialogClose() method is called from within the parent page.

It takes two parameters, the result which should be one of the members of the SP.UI.DialogResult enumeration and the arguments, which can be any kind of variable or object returned from the dialog page.

Additionally in here you can call SP.UI.ModalDialog.RefreshPage() – this method takes a single parameter and is designed to be called using the result value from your callback. This method ensures that the page refreshes if the result is equal to SP.UI.DialogResult.OK

With these three sections we can define how our dialog looks, what data it takes in, and what happens once it is closed and how to process the data that comes back from it.

Lastly the dialog itself is opened using the call to SP.UI.ModalDialog.showModalDialog()

Now lets take a look at the other side of the coin, here’s the JavaScript code to run within the dialog page.

(function() {

	// As on the parent page, wait for the DOM and SharePoint to be ready before doing anything.
	$(document).ready(function() {
		ExecuteOrDelayUntilScriptLoaded(function() {

			// retrieve a reference to the page that called us.

			var _parent = SP.UI.ModalDialog.get_childDialog();

			// If this is false, then chances are you have browsed to the page directly rather than
			// loaded it in a modal window.
			if (_parent) {

				// Pull through the arguments sent to the dialog.
				var args = _parent.get_args();

				// set a red alert status line with our argument.
				var status = SP.UI.Status.addStatus("someKey:", args.someKey);
				SP.UI.Status.setStatusPriColor(status, "red");
				
				// Add handlers for our ok and cancel buttons
				$("#okButton").click(function() {
					// This closes the modal dialog and runs the callback method defined on the parent page.
					SP.UI.ModalDialog.commonModalDialogClose(SP.UI.DialogResult.OK, args);
				});

				$("#cancelButton").click(function() {
					SP.UI.ModalDialog.commonModalDialogClose(SP.UI.DialogResult.Cancel, "cancel clicked");
				});

			}

		}, "SP.UI.Dialog.js");
	});
})();

This again is fairly simple, we first of all get a reference to the calling page in the variable _parent. Then if that has been successful we pull in the args object from our options variable above.

Once at this point the world is your oyster, you can use the arguments from the parent page however you wish to display the dialog or interact with your users.

To close the dialog you can use SP.UI.ModalDialog.commonModalDialogClose(). This again takes two parameters, the first should be a member of the SP.UI.DialogResult enumeration, the second can be any object to send back, these map to the variables sent to our callback function above.

Additionally in here I have made use of some of the other neat parts of the SP.UI namespace such as the status bar and notification system. These are beyond the scope of this post but they’re pretty awesome and you should go read about them.

So there we go, by now you should be able to add true SharePoint style dialogs to your pages with minimal effort.

via Chris on SharePoint http://spchris.com/2013/04/dr-popup-or-how-i-learned-to-stop-worrying-and-love-the-modal-dialog/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

The excellent Knockout.js library is an MVVM (Model, View, ViewModel) library.

Using it you can completely abstract the logic from the presentation in your web applications, allowing dynamic and responsive UIs to be created without having to manage all of the fiddly UI updates directly.

The Knockout site has a great set of tutorials on how to use it, but I thought I would bring them into a SharePoint context.

Specifically, I am going to cover their 5th tutorial, Loading and Saving Data. In this tutorial they give the example of a simple task list that a user can update and delete dynamically. If you do not know Knockout at all, I recommend you go through this tutorial before continuing. Go ahead, I can wait.

Back with us? Excellent. Hopefully by now you have some idea of the power of Knockout, so lets try and reproduce this using a SharePoint list as the data source.

The first thing to do is to create our list. For this I am using a simple custom list named ‘My Tasks’ with an additional Completed Yes/No field, and I have pre-populated it with some entries.

Next we need to consider how we are going to create our view within our site. For my example I have chosen to simply create the view as a file in a document library, then link to it using a Content Editor Web Part. However you could do this a number of ways, you could embed your JavaScript into the master page and put your data bindings directly into a page layout, or you could create a visual web part. The possibilities are endless, this is SharePoint after all!

I put the view, along with the script references to Knockout, the ever useful jQuery and my View Model into a single file and save it into the document library. I have also put some style information in too. Here is the view model as I created it:

<style type="text/css">

	#taskContainer {
		width: 500px;
	}
	
	#errorBox {
		text-align: center;
		border: 1px solid #600;
		margin-bottom: 10px;
		padding: 10px;
		background: #f99;
		color: #600;
	}
	
	#saveBox {
		text-align: center;
		border: 1px solid #060;
		margin-bottom: 10px;
		padding: 10px;
		background: #9f9;
		color: #060;
	}
	
	#taskContainer ul {
		padding: 10px;
		background: #eaeaea;
		padding: 0;
	}
	
	#taskContainer ul li {
		list-style: none;
		padding: 3px;
	}
	
	#taskContainer input[type=text] {
		width: 390px;
	}
	
</style>
<div id="taskContainer">
	<h3>Tasks</h3>
	
	<div id="errorBox" data-bind="text: errorMessage, visible: errorMessage"></div>
	<div id="saveBox" data-bind="text: saveMessage, visible: saveMessage"></div>
	
	Add task: <input data-bind="value: newTaskText" placeholder="What needs to be done?"/>
	<button data-bind="click: addTask">Add</button>
	
	<ul id="myTaskBox" data-bind="foreach: tasks, visible: tasks().length > 0">
	    <li>
	        <input type="checkbox" data-bind="checked: Completed" />
	        <input data-bind="value: Title, disable: Completed" />
	        <a href="#" data-bind="click: $parent.removeTask">Delete</a>
	    </li> 
	</ul>
	
	You have <b data-bind="text: incompleteTasks().length">&nbsp;</b> incomplete task(s)
	<span data-bind="visible: incompleteTasks().length == 0"> - it's beer time!</span>
	
	<button data-bind="click: save">Save</button>
</div>

<script type="text/javascript" src="../webdevdocuments/knockout.js"></script>
<script type="text/javascript" src="../webdevdocuments/jquery-1.9.1.min.js"></script>
<script type="text/javascript" src="../webdevdocuments/ViewModel.js"></script>

Note the addition of some message boxes, the original tutorial does not include them but I felt they were nicer than simple alert boxes.

Also note that, unlike the original, I have not used a form element for the new task area. This is because form elements can cause havoc in SharePoint pages, as the entire page is wrapped in a form for post-backs.

Other than that, our view is mostly unchanged.

Now, on to the JavaScript!

The main differences here lie in the way that we send and receive data from SharePoint. In their examples they use jQuery to query and post data to REST APIs, and while SharePoint 2010 and 2013 do come with their own suite of REST / oData APIs, there are some issues in using them.

• Update and Delete calls can only update or delete one item per call, to do the bulk updating this system indicates we would have to make a request per item. Not ideal!
• Due to the way SharePoint handles concurrency, you have to pass around an eTag so that SharePoint can determine if an item has been updated since requested. While this is great for high concurrency systems with multiple people editing the same data, for a personal tasks list this is not a nice feature.

Luckily REST is not our only option. SharePoint has the wonderful Client Side Object Model (CSOM), which can do all of our loading and saving for us!

Here is my View Model, updated to use the CSOM.

(function() {

	function Task(data) {
	    this.Title = ko.observable(data.Title);
	    this.Completed = ko.observable(data.Completed);
	    
	    // An additional reference to store the SharePoint list item id.
	    this.Id = ko.observable(data.Id);
	}
	
	function TaskListViewModel() {
	    // Data
	    var self = this;
	    self.tasks = ko.observableArray([]);
	    self.newTaskText = ko.observable();
	    
	    // Additional bindings to use for error and saved messages.
	    self.saveMessage = ko.observable(false);
	    self.errorMessage = ko.observable(false);
	    
	    self.incompleteTasks = ko.computed(function() {
	        return ko.utils.arrayFilter(self.tasks(), function(task) { return !task.Completed() && !task._destroy});
	    });
	
	    // Operations
	    self.addTask = function() {
	        self.tasks.push(new Task({ Title: this.newTaskText(), Completed: false, Id: "New" }));
	        self.newTaskText("");
	    };
	    
	    self.removeTask = function(task) {
			self.tasks.destroy(task)
	    };
	    
	    self.save = function() {

	    	for (var task in self.tasks()) {
	    	
	    		var createdTasks = [];
	    		
	    		// Build a request up to send with the CSOM.
	    	
	    		if (self.tasks()[task]._destroy) {
					// Handle deleted objects
	    			// Deleted items that are marked "new" have never been saved to SharePoint to start with,
	    			if (self.tasks()[task].Id() != "New") {
			    		var listItem = taskList.getItemById(self.tasks()[task].Id());
			    		listItem.deleteObject();
	    			}
	    		} else if (self.tasks()[task].Id() == "New") {
	    			// Handle new objects to be created.
	    		
	    			var createInfo = new SP.ListItemCreationInformation();
	    			var listItem = taskList.addItem(createInfo);
	    			
	    			listItem.set_item("Title", self.tasks()[task].Title());
	    			listItem.set_item("Completed", self.tasks()[task].Completed());
	    			
	    			listItem.update();
	    			
	    			// Save a reference to both the SP.ListItem object and the KO Object so we can update
	    			// the latter with the former's ID once the object has been created.
	    			createdTasks.push({
	    				spItem: listItem,
	    				koItem: self.tasks()[task]
	    			});
	    			
	    			ctx.load(listItem);
	    		} else {
	    			// The item is neither new nor deleted, handle it as an update.
	    			var listItem = taskList.getItemById(self.tasks()[task].Id());
	    			
	    			listItem.set_item("Title", self.tasks()[task].Title());
	    			listItem.set_item("Completed", self.tasks()[task].Completed());
	    			
	    			listItem.update();
	    		}
	    		
	    	}

			// Nowe we have built our request, send it to the server for processing.	    	
	    	ctx.executeQueryAsync(function() {
	    	
	    		// Our save was successful. Now we need to itterate through our newly
	    		// created items and ensure that Knockout knows that the ID has changed.
	    		for(var item in createdTasks) {
	    			createdTasks[item].koItem.Id(createdTasks[item].spItem.get_id());
	    		}
	    		
	    		// Set our saved message.
	    		self.saveMessage("Saved successfully");
	    		
	    	}, function(sender, args) {
	    	
	    		// Our save failed, set the error message to show then log the actual error
	    		// to the JavaScript console if it exists.
	    		self.errorMessage("Error updating list items");
	    		if (typeof console != "undefined") {
	    			console.log(args.get_message());
	    		}
	    	});
	    	
	    };
	    
	    // Load the data from SharePoint
		// Get a context to the current site.
	    var ctx = new SP.ClientContext(_spPageContextInfo.webServerRelativeUrl);
	    
	    var web = ctx.get_web();
	    var taskList = web.get_lists().getByTitle("My Tasks");
	    
	    // Limit our task list to 50 tasks.
   	    var query = new SP.CamlQuery();
   	    query.set_viewXml("<View><RowLimit>50</RowLimit></View>");
   	    
   	    var taskItems = taskList.getItems(query);
   	    
   	    // Ensure the fields we want to retrieve are returned
   	    ctx.load(taskItems, "Include(ID,Title,Completed)");
   	    
   	    // Send our query to the server for processing.
   	    ctx.executeQueryAsync(function() {
   	    	var tasks = [];
   	    	var taskItemEnumerator = taskItems.getEnumerator();
   	    	
   	    	// Iterate through our retrieved data set and build an array of JSON objects containing
   	    	// the relevent properties.
   	    	while (taskItemEnumerator.moveNext()) {
   	    		tasks.push(
   	    			new Task({
	   	    			Title: taskItemEnumerator.get_current().get_item("Title"),
	   	    			Completed: taskItemEnumerator.get_current().get_item("Completed"),
	   	    			Id: taskItemEnumerator.get_current().get_item("ID")
	   	    		})
	   	    	);
   	    	}
   	    	
   	    	// Update the Knockout tasks array with our data from the server.
   	    	self.tasks(tasks);
   	    });
	    
	}
	
	
	$(document).ready(function() { // I use jQuery for this, but you could add an event listener to the document object instead.
		EnsureScriptFunc("sp.js", "SP.ClientContext", function() {
			ko.applyBindings(new TaskListViewModel());
		});
	});

})();

So there you go, once you put it all together you should end up with something looking like this:

Cool, huh? It is by no means perfect. The two biggest issues with the implementation as it stands are:

• Currently I am limiting the entire system to only showing 50 records, which is not ideal. This would be best handled by adding some pagination.
• When you hit save it updates every item in the view model, regardless of whether it needs updating or not. This would be resolvable by subscribing to the Task Knockout object and keeping track of which need updating and which do not.

Additionally you could use some jQuery animation and the animated transitions example on the Knockout site to hide the save and error boxes once they are shown. Currently once they are visible they remain visible indefinitely.

Have fun with it, it’s a neat tool and can give quite powerful results.

via Chris on SharePoint http://spchris.com/2013/04/using-knockout-js-in-a-sharepoint-context/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

Today I had a requirement to alter the title in the left hand side of the Suite bar in SharePoint 2013.

This is the bar appearing at the very top of the page, by default containing the word SharePoint on the left and links to things like SkyDrive, the Newsfeed and sites you follow on the right.

In this particular scenario I was interested in changing the word SharePoint to something more meaningful, preferably customisable on a per web basis, or based upon the site collection root web’s title.

My first thought on trying to change it was to look into the master page but I could find no reference to it there, so I did a little digging and found some surprising details.

1. The entire bar is a delegate control
2. The left hand part of the bar is stored as a property against the Web Application
3. There is no way of modifying the right hand links without writing a farm solution in .NET, or adding custom JavaScript to each page to modify the links on the fly.

While these problems are not insurmountable, it left me a little nonplussed, especially the idea that it was not possible to modify the branding uniquely per site collection or per web. However I bravely fought on, as I was really quite determined to get that heading working the way I wished.

My first test was to see what the property against the web application was called, and what it contains by default. Let’s break out our trusty SharePoint Management Console and use the following bit of PowerShell.

$webApp = Get-SPWebApplication -Identity "http://mywebapplicationurl"
$webApp.SuiteBarBrandingElementHtml
<div class="ms-core-brandingText">SharePoint</div>

This seems straight forward enough, the property is a string containing the HTML for the heading, so let’s go and update it to something else using the same window from our previous example (Re-do the Get-SPWebApplication call again if you have closed it)

$webApp.SuiteBarBrandingElementHtml = '<div class="ms-core-brandingText">My Custom Branding</div>'
$webApp.Update()

Note the call to the Update() method, without this your changes will not be applied to the Web Application.

Once done, refresh your page and you will see that your branding has updated accordingly.

So to recap, we can modify this string only on the Web application level, but when we do so, we can put HTML tags in directly, and they will be rendered to the page. Interesting!

Let’s talk about JavaScript

The ECMAScript Object Model first came into its own with SharePoint 2010, and with 2013 has gone from strength to strength. Lets see if we can’t use it to meet our requirement of at least customising the Suite bar based on the current Site Collection’s root web title.

To do this is very simple in code, take a look at the following JavaScript example:

(function() {

	// Set a default title to use if we cannot retrieve one.
	var defaultTitle = 'SharePoint';

	// Ensure that both the DOM and the Object Model are ready for us
	document.addEventListener('DOMContentLoaded', function() {
		EnsureScriptFunc('sp.js', 'SP.ClientContext', function() {

			// Instantiate our renamer.
			var t = new titleBarRenamer();

		});
	});


	function titleBarRenamer() {

		// Get and load a reference to the root web of the current site collection.
		var ctx = new SP.ClientContext.get_current();
		var site = ctx.get_site();
		var rootWeb = site.get_rootWeb();

		ctx.load(rootWeb);

		// Send our query off to SharePoint.
		ctx.executeQueryAsync(function() {

			var title = false;

			// Pull the title into a variable.
			// Default to the default title if it fails.

			try {

				title = rootWeb.get_title();

				title = title || defaultTitle;

			} catch (e) {

				title = defaultTitle;

			}

			// Update our title to our results.
			document.getElementById('webTitleContainer').innerHTML = title;

		}, function() {

			// If all else fails, set the title back to our default.
			document.getElementById('webTitleContainer').innerHTML = defaultTitle;

		});
	
	}

})();

That’s cool, wherever this code is run it will set an HTML element with an ID of ‘webTitleContainer’ to the root web’s title.

Putting it all together

So how do we combine these two together?

Again this is pretty simple, take a look at the following PowerShell:

Add-PSSnapIn Microsoft.SharePoint.PowerShell

$containerCode = @"
<div id='webTitleContainer' class='ms-core-brandingText'></div>
<script type='text/javascript'>
(function() {

	// Set a default title to use if we cannot retrieve one.
	var defaultTitle = 'SharePoint';

	// Ensure that both the DOM and the Object Model are ready for us
	document.addEventListener('DOMContentLoaded', function() {
		EnsureScriptFunc('sp.js', 'SP.ClientContext', function() {

			// Instantiate our renamer.
			var t = new titleBarRenamer();

		});
	});


	function titleBarRenamer() {

		// Get and load a reference to the root web of the current site collection.
		var ctx = new SP.ClientContext.get_current();
		var site = ctx.get_site();
		var rootWeb = site.get_rootWeb();

		ctx.load(rootWeb);

		// Send our query off to SharePoint.
		ctx.executeQueryAsync(function() {

			var title = false;

			// Pull the title into a variable.
			// Default to the default title if it fails.

			try {

				title = rootWeb.get_title();

				title = title || defaultTitle;

			} catch (e) {

				title = defaultTitle;

			}

			// Update our title to our results.
			document.getElementById('webTitleContainer').innerHTML = title;

		}, function() {

			// If all else fails, set the title back to our default.
			document.getElementById('webTitleContainer').innerHTML = defaultTitle;

		});
	
	}

})();
</script>
"@

$webApp = Get-SPWebApplication -Identity "http://mywebapplicationurl"
$webApp.SuiteBarBrandingElementHtml = $containerCode
$webApp.Update()

As you can see, the bulk of this is our JavaScript code from above, with the addition of a div for our title to end up in and the required script tags for the code.

Once you have this, you can save it as a .ps1 file and execute it in PowerShell. You may need to set the execution policy to RemoteSigned before you are able to do this.

And there you go. You could do some fairly interesting things with this, particularly as it takes effect right across the entire web application. You also have to be aware that this is stored within the Configuration Database rather than the Content Database, so will not be migrated if you move content databases from one farm to another.

via Chris on SharePoint http://spchris.com/2013/04/mastering-the-sharepoint-2013-suite-bar/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

The User Profile Service is an incredibly powerful part of SharePoint. When used correctly it vastly improves the experience of your users by adding a real sense of personal ownership of your sites and their content.

Unfortunately like any complex system, identifying and fixing issues can be a painful process. There is minimal information provided in the site and almost none regarding the connection between the service and Active Directory.

In SharePoint 2010, the user profile sync is controlled by the ForeFront Identity Manager service, this is a Windows service that handles the connections between Active Directory, any BDC connections defined and the SharePoint site collections and sites.

The workings of the service are somewhat impenetrable, but if you wish to see what it is doing and follow the sync process, it comes with a nice GUI interface.

This can be run directly on the server from the path X:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe

When running during a sync you can see any issues encountered such as permissions problems.

via Chris on SharePoint http://spchris.com/2013/04/forefront-identify-manager-client/

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)

Quite often when working with data within a SharePoint environment, we wish to link the data to images hosted within a third party system.

This is often seen in the form of staff pictures that are hosted on a third party HR platform rather than within Active Directory, so the User Profile service images are of no use to us.

Unfortunately there is no real way of detecting if the image on the third party system actually exists, which means that rather than seeing the nice friendly missing profile image, you get a horrible missing image box.

This can be overcome with some simple JavaScript:

(function(){

    var defaultImage = "/_layouts/15/images/PersonPlaceholder.200x150x32.png";

    var profileImage = document.createElement("img");

    // Define an error handler, this will fire if there is an
    // error loading the URL for the staff image and redirect
    // it to the missing user profile image in the hive.

    profileImage.onError = function() {

        this.src = defaultImage;

    }

    // Point the image element to our staff images then attach
    // it to the DOM.

    profileImage.src = "http://hr/staffimages/" + employeeId + ".png";

    // Note that the employeeId variable referenced above is to be
    // provided externally and is beyond the scope of this post.

    var container = document.getElementById("profileImageContainer");

    if (container) {
        container.appendChild(profileImage);
    }
})();

With this code in place any missing images will automatically serve the default image instead.

This method will work anywhere you need to serve images and have no way of detecting if the image to be served exists or not.

SharePoint and Project Server Consultant MCITP – SharePoint Administrator 2010 MCTS – Microsoft Project 2010 – Managing Projects, Project Server 2010, Configuration, SharePoint 2010, Configuration Prince 2 – Practitioner This article has been cross posted from spchris.com (original article)