10 aspects of your SharePoint environment that prevent growth, and how to overcome them


Adopting SharePoint into your company’s future is excellent choice, but most are not planned out for growth. Just as the first house you buy is usually not your last, the first go-around of SharePoint may not be the healthiest. Here are some points that you may want to consider changing to better suit SharePoint and its success and productivity in your company.

1. Everything in one site collection

Whenever SharePoint goes from an idea to an idea in motion, there usually isn’t much planning involved. Most companies and IT departments want to break SharePoint open to see what it can do and how they can best utilize it–and rightfully so. This is especially true in small IT departments, where decentralization comes into play. However, once it starts to grow, the structure sticks. Having all content in one site collection seems like a benign decision at first, but the problems start to creep up whenever more users start to using SharePoint in their daily workday. Sites can seem slow, especially with resource-intensive services such as Search, Excel Services, and PerformancePoint.

Microsoft recommends having a departmental structure. Having one site collection per department works, because it isolates permissions, and allows users to easily find a file, team resource, project leader, calendar, or that one document that they saw last week, etc.

Solution: PowerShell scripts can come to the rescue here, breaking out each subsite into their own site collection. There are also 3rd party tools that can accomplish the same task for you.

2. All site collections in one content database

This goes with the first point, but should be a very simple fix. Having multiple site collections are great to segregate data into their respective categories and an isolated security model. However, part of the reason to separate them into site collections is for the added benefit of having them in different content databases. Site collections are the lowest logical structure that allows for a separate content database. This increases performance and is easier to maintain. DBA’s will thank you for it! It’s much nicer to see lots of smaller databases rather than one large database.

This also helps the practice of testing with a testing environment, which I will cover later. In short, if you are working on testing a feature for a specific site collection, no need to back up the entire SharePoint content. If you need to focus on one site collection, you can backup one smaller content database.

Solution: Powershell is the choice here as well. There is a SharePoint PowerShell cmdlet called Move-SPSite that should be a one-liner in moving a site collection to a different content database.

3. Document libraries with no versioning

Many companies think of SharePoint for document storage. Storing, editing, sharing documents is at the heart of a classically used SharePoint environment. However, many do not utilize a very important feature of the document libraries–versioning. This feature has saved users from themselves and others more times than I can count.

Imagine working on a document and you go to save your document, and you or someone else drastically changes the document, not to your liking or erroneously editing the wrong cells in Excel and all the formulas mess up–but it’s already been saved. Just as the recycle bin saves users from themselves for deleting documents, versioning comes in handy for erroneous changes. If you plan on using a library for highly active documents, consider turning on versioning. There is also another setting that tells SharePoint to keep only a certain number of versions, and to delete anything older.

Solution: Turn on versioning in the advanced settings of the libraries that you want turned on.

4. Pushing hardware to the limit, not scaling up/out

When SharePoint grows out of the trial stages, some environments should be scaled up or out to allow better performance. Some topologies start out with just enough to get by, a trial-basis environment, or even an all-in-one server. When the number of normal end-users are growing exponentially, then it’s time to reevaluate if the current topology fits.

Scaling up involves beefing up the hardware. I would recommend increasing the memory on the servers first, starting with the SQL Server. Scaling out is adding more servers to the farm. The type of server depends on your environment and how you are using SharePoint, but adding a 2nd web front end, may probably be the best option if you only have one web front end. If you are adding your 2nd web front end, I would also look into using a network load balancer–whether hardware related or software related. Windows Server provides a Network Load Balancer which is a starting place.

Solution: It depends on the most used aspect of SharePoint. A list of typical topologies is a good place to start: https://technet.microsoft.com/en-us/library/cc263199.aspx#architecture

5. Too many farm solutions

Don’t get me wrong, customization is good…to an extent. Most companies that miss the target do so because they are using a lot of farm solutions to customize everything under the sun. The most practical use for farm solutions I’ve seen is branding. Branding is the customization of the look and feel to “brand” your SharePoint site to your liking. Most companies I’ve seen use branding primarily for a custom navigation, and secondly to give SharePoint a familiar face, possibly one that imitates an intranet or public facing website.

Whenever SharePoint developing came around, server-side code was very popular, and it got the job done. As SharePoint versions incremented, more and more push to the cloud became more prevalent. Any sort of customization nowadays is recommended to be client-side. This also paves the migration path to SharePoint Online, which does not include farm solutions. Microsoft continues to update the client-side technology through Cumulative Updates to increase exposure to SharePoint objects that you would normally have to use farm solutions to access. This makes moving to client-side development more possible.

Solution: Minimize the number of farm solutions if you can. First, plan to develop new customizations using client-side or using apps. Second, redevelop solutions that are crucial to your business needs in client-side or using apps, if possible. Start with the less-used and least complex farm solutions, and move to more used and most complex farm solutions.

6. No dedicated SharePoint Administrator

Whenever SharePoint gets big enough, it grows out of becoming a side project. Your best bet is to hire a SharePoint Administrator. I’d recommend this if you have at least 300 people using SharePoint especially if end-users rely on SharePoint on a daily basis to get their work done.

A good SharePoint Administrator will take care of your environment, recommend changes, support your users, and keep things running smoothly. It really is a full-time job and then some. Some companies with large environments will have a SharePoint team. The features, size, and capabilities of SharePoint make it impossible to manage part-time. This is especially true with enthusiastic users that want to expand on their department’s exposure of SharePoint. Allowing your users to build on their SharePoint presence will drastically increase adoption. A SharePoint Administrator will help facilitate new changes and make sure your users are being productive using SharePoint.

Solution: Hire a SharePoint Administrator, or hire from within the company and send them to training.

7. All services are being run by one or two accounts

Microsoft recommends to segregate service accounts into respective accounts, instead of running all services under one account. This is for a vareity of reasons. Mainly for security. If one of the accounts is compromised, the account can be changed without much headache. Another reason is separation of responsibilities. If an account needs permission or access, it’s best to give that account just enough permission to get by. This practice is known as least-privileged administration. Learn more here.

I would recommend several accounts, each being specific to several distinct services, including but not limited to: sp.install, sp.farm, sp.apppool, sp.mysites, sp.search, sp.crawl, sp.profilesync, sp.services, sp.workflow, sp.unattended. More on SharePoint service accounts here.

Solution: Create the services above and change the service accounts in Central Administration. You may also have to add the account to SQL permissions or the local Administrators on the SharePoint servers. Follow the guide linked above.

8. Being out of date

This one should not be a big shocker. Whether it’s installing a cumulative update or hotfix, updating should be a practice that is a should not be taken lightly. SharePoint updates are a little more fragile than just leaving automatic updates on. With the right person, it should be a simple process that keeps your company on par with a healthy SharePoint environment.

SharePoint migrations are an even bigger animal. Migrating from SharePoint 2010 to SharePoint 2013 is big project. Depending on how big the environment is, migrating to the next version can take months of planning and testing. There are plenty of factors to take into account, including customization, branding, workflows, and environmental variables. Depending on how big your SharePoint environment is, migrations require a team of professionals from your company, including network and system administrators, DBAs, software engineers, and business analysts.

SharePoint 2010 moved into the extended support lifecycle as of October 2015. This means there will be no future design changes, and bug fixes are only provided for those with that purchased an Extended Hotfix Support.  SharePoint 2007 has until October 2017 until there is no support from Microsoft. That means you are on your own with the software–use at your own risk.

Solution: Plan for your software update or SharePoint migration if you are out of date. Gather your team and talk about the pros and cons of migration and plan accordingly. Follow the software upgrade and SharePoint migration guides.

9. Continuing to use and develop new forms in InfoPath

This goes along the same lines as using customization. It has been confirmed by Microsoft that InfoPath Services will not be part of SharePoint Server 2016, and InfoPath will not be part of Office 2016. This leaves the migration paths with InfoPath forms to a) use SharePoint Designer custom forms, b) use third-party form solutions, c) use form solutions outside of SharePoint, or d) use InfoPath client. There are probably other migration paths in the future, but Microsoft has not released any tool or feature that allows InfoPath forms to be translated, and frankly, most of the SharePoint community doesn’t think it’s coming.

The best thing to do, in my opinion, is to switch to using SharePoint Designer forms. It’s free, and it has a lot of customization potential by using HTML5/CSS3, REST API and CSOM/JSOM. Make sure that any efforts made to migrate is done using client-side development, not farm solutions, unless it’s by a third-party retail solution such as Nintex Forms.

InfoPath is still supported and moving forward, you have just under a decade before support ends for SharePoint 2013. With that amount of time, I think you should be able to change all the forms you have as long as you have the right people involved.

Solution: Start with the simple and less used InfoPath forms and work your way out to the more complex and most used forms last. Plan a migration path and notify your users of the change. Also cease all new projects involving InfoPath forms.

 10. No test environment

Every healthy SharePoint implementation has a test environment. It’s one of those items on the list that people miss, but it’s important for testing any new features that are associated with SharePoint. You can test third-party solutions and webparts, new customizations, new development, test code, test the features and services, all without breaking production. If you are going to build a new test environment, though, there are some key points that make it more useful.

One thing to make sure of is to always have the development environment build match the build of production. That means the same service pack and the same build (cumulative update). You should be able to find the build you are using in Central Admin -> Servers in this farm. Production and development environments that share the same build can transfer databases, which is helpful for testing out customizations and code on production data.

Another point is to have the test environment on the same domain. This allows any references to the domain to work, allows for users in the domain to be referenced in any workflows, lists, and custom code, and also allows permissions to be transferred. For example, if you backup a production content database, and restore it to the development farm, having a matching build will allow you to mount that database to the SharePoint farm, otherwise the schema would not match and you will receive an error. Whenever that database is mounted, you should immediately be able to browse to it, and with having the same domain, the same permissions will be applied.

Solution: Build a test environment in the same domain, and patch it up to the same build as production. Put Visual Studios and SharePoint Designer on it for developers and SharePoint administrators to use.

 

Having a SharePoint environment can really help companies thrive and expand their reach to others, but comes with a caveat–you must configure it for growth. These points can ensure that your SharePoint users are using SharePoint in the most productive way possible: by increasing performance, maintaning supportability, providing room for growth, and being in a state of good practice according to Microsoft. These points all depend on the company, and may not always be the best option, but are suggested for most companies.

Moving Search Index


There will be times where the Search is either on the wrong server, or you want to move the index on another drive. There have been times where I’ve done this in the past, but I think the mistake I’ve made is deleting the old index at the same time as creating the new index. In this demonstration, I allow the new and old index to live at the same time, in order to sync the index between the two. After the sync is complete, you can THEN remove the old index location/server and reset the topology.

Add-pssnapin microsoft.sharepoint.powershell

$serv1 = Get-SPEnterpriseSearchServiceInstance -Identity "SPAPP1"

$serv2 = Get-SPEnterpriseSearchServiceInstance -Identity "SPAPP2"

$ssa = Get-SPEnterpriseSearchServiceApplication

$active = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -Active

$clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone -SearchTopology $active

 

New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance $serv2 -IndexPartition 0 -RootDirectory "D:\Index"

 

Get-SPEnterpriseSearchComponent -SearchTopology $clone -SearchApplication $ssa

Set-SPEnterpriseSearchTopology -Identity $clone

 

Get-SPEnterpriseSearchStatus -SearchApplication $ssa

 

#The “Degraded” Status just means that the index is syncing between the existing index and the new index.

#Once the Index is “Active” begin to remove the old index

 

#Get Index GUID of old index

Get-SPEnterpriseSearchComponent -SearchTopology $clone -SearchApplication $ssa

 

#Removing the old index and setting topology to a clone without the old index

$ssa = Get-SPEnterpriseSearchServiceApplication

$active = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -Active

$clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone -SearchTopology $active

Remove-SPEnterpriseSearchComponent -Identity GUID_OF_Index_Component -SearchTopology $clone

Set-SPEnterpriseSearchTopology -Identity $clone

 

Once the index is sync’d and online, you should be good to go!

 

Beware of the ControlMode of SharePoint:FormField


My client has custom forms for a list in SharePoint 2010. Display/Edit/New all have customization. Within this customization there are your common SharePoint FormField and FieldDescription tags such as:

<SharePoint:FormField runat=“server” id=“ff2{$Pos}” ControlMode=“New” FieldName=“Title” __designer:bind=“ddwrt:DataBind(‘i’,concat(‘ff2′,$Pos),’Value’,’ValueChanged’,’ID’,ddwrt:EscapeDelims(string(@ID)),’@Title’)}”/>

<SharePoint:FieldDescription runat=“server” id=“ff2description{$Pos}” FieldName=“Title” ControlMode=“New”/>

Be aware of the “ControlMode“. This will be tied to your SPBasePermissions, which I’ve tried to override using the SPTrimmedControl block–which that does not work. Using the ControlMode=”Edit” will give users an access denied when trying to view using a user that only has Read permissions. In order to view ControlMode=”Edit”, the user needs to have Contribute permissions. Therefore, if the user has only Read permissions, the ControlMode must equal Display.

The context of the problem arose when I used the Edit ControlMode in the Display Form, and using jQuery to disable the textbox for just viewing. Sometimes the textboxes of the fields just look cleaner and are easier to read.

PSConfig Configuration Failed


I had a client that I was applying a patch to and the PSConfig failed. Usually, I know that if it fails once, for good measure you are supposed to try to run the PSConfig again (always run as administrator with the install account)…..but it failed again. Okay….what’s going wrong? I looked more into the logs and it told me that the Usage and Health database was part of a mirror or availability group.

04/10/2015 09:01:33.82  OWSTIMER (0x530C)      0x3FC8  SharePoint Foundation Upgrade                SPUpgradeSession          aj0ur      ERROR  Upgrade Timer job is exiting due to exception: System.Data.SqlClient.SqlException (0x80131904): The operation cannot be performed on database “SP13_UsageAndHealth” because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.  ALTER DATABASE statement failed.     at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)     at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)    

Once I removed the Usage and Health database from the availability group, and ran the PSConfig again, it succeeded.

Is this a database that really shouldn’t be in the AlwaysOn availability group? That’s odd to me. I wonder if newer patches will recognize this, and allow this database to be in the AlwaysOn availability group.

Happy SharePointing!

FIM Sync error


I had an implementation which had a FIM Sync problem that it would find all the AD objects that it needed to find, but the user profile sync wouldn’t create the profiles, which remained at 0. In the ULS logs you may see something along the lines of “Unsupported Method”, going to the UIShell of the sync service in “C:\Program Files\Microsoft Office Servers\Synchronization Service\15.0\UIShell\miisclient.exe” you may see the error “stopped-extension-dll-load“, but there is no additional information about it. In your event viewer you may find:

The management agent “MOSS-UserProfile” failed on run profile “MOSS_EXPORT_GUID”. The run step stopped because a configured extension for this management agent could not be loaded.

User Action
Verify that the extension is located in the Extensions directory. If the extension is present, confirm that the version of the .NET framework that can run the extension is installed on the server and that a supportedRuntimes entry in the configuration files specifies that version. The synchronization engine will not be able to load an extension that is built with a newer version of the .NET framework than the version of the .NET runtime it is hosting.

Turns out that this is somehow due to the supported runtime being commented out in miisserver.exe.config

<startup useLegacyV2RuntimeActivationPolicy=”true”>
<!– <supportedRuntime version=”v4.0.30319″></supportedRuntime> –>
<supportedRuntime version=”v2.0.50727″></supportedRuntime>
</startup>

Delete uncomment the line to make it look like this:

<startup useLegacyV2RuntimeActivationPolicy=”true”>
<supportedRuntime version=”v4.0.30319″></supportedRuntime>
<supportedRuntime version=”v2.0.50727″></supportedRuntime>
</startup>

Restart the server that hosts the Sync Service. You can find out by going to CA -> Manage Service Applications -> Highlight User Profile Service -> Properties

Creating New Multi-Lookup Values from Custom Forms


I was working with a client where they wanted to add a new Multi-Lookup value on the New Item form. This will be a customized new item form that will add a link to popup a new item of that multi-lookup value. SPServices has something that will add the SPLookup (http://spservices.codeplex.com/wikipage?title=$().SPServices.SPLookupAddNew&referringTitle=Documentation), but wasn’t verified for SharePoint 2013 and had caveats for 2010, so I was unsure about the solution. I read some blogs that show you how to explicitly add a new lookup value, using the following format:

|t<ID>|t<LOOKUPVALUE>|t

where <ID> = the ID of the lookup item and <LOOKUPVALUE> = the lookup value/text of the item

The tricky part to this is that there are <select> tags and <input> tags that are hidden that you need to add and remove, this will force you to reinvent the wheel of adding and removing the option from the two panel display:

 

I think I was tackling it from a different angle, so I just used the refresh and with HTML5, you have the ability to use localStorage. localStorage is used for what cookies previously was used for in the prior versions. You can write and store key/value pairs that will stay with the browser even after you close the browser out (much like a cookie). So I think it may be easier to capture the values of the form, and reinsert the values whenever the new item is added and the form is refreshed.

<script type=”text/javascript” src=”../../Style Library/js/jquery-1.11.1.min.js”></script>
<script type=”text/javascript”>
$(document).ready(function(){

$(“input[id$=’TextField’]”).filter(“input[title=’Name’]”).val(localStorage.getItem(‘name’));
$(“input[id$=’TextField’]”).filter(“input[title=’Address’]”).val(localStorage.getItem(‘address’));
$(“input[id$=’TextField’]”).filter(“input[title=’Address 2′]”).val(localStorage.getItem(‘address2′));
$(“input[id$=’TextField’]”).filter(“input[title=’City’]”).val(localStorage.getItem(‘city’));

localStorage.removeItem(‘name’);
localStorage.removeItem(‘address’);
localStorage.removeItem(‘address2’);
localStorage.removeItem(‘city’);

});

function AddNewRig()
{

OpenPopUpPage(‘/../../Lists/<List>/NewForm.aspx?IsDlg=1′,  AddItemRefresh);
}

function AddItemRefresh()

{

var name = $(“input[id$=’TextField’]”).filter(“input[title=’Name’]”).val();
var address = $(“input[id$=’TextField’]”).filter(“input[title=’Address’]”).val();
var address2 = $(“input[id$=’TextField’]”).filter(“input[title=’Address 2′]”).val();
var city = $(“input[id$=’TextField’]”).filter(“input[title=’City’]”).val();
localStorage.setItem(“name”, name );
localStorage.setItem(“address”, address);
localStorage.setItem(“address2”, address2 );
localStorage.setItem(“city”, city);
location.reload();

}

</script>

 

Basically, upon loading the form, it will look for the localstorage keys, then set the form values for each textbox/control. You then delete the keys so that it doesn’t conflict with any other applications that use it. SharePoint will handle the loading of the Multi-lookup control with the new item that the user just created, so whenever you refresh the page, the form will load the Item you just added while retaining any information that the user previously put inside the form. A new key/value pair will have to be set/get/deleted for each column or field in the form.

 

Workflows running twice


I’ve found that in some cases during a migration, workflows may have the ability to run twice. You can even start a brand new workflow for a list, and even that will run twice. I looked more into it, and it appears that upon migration, both the 14 and 15 version event receivers were present. I did some powershell to find and remove the 14 (I’m on SP2013) event receivers.

$spWeb = Get-SPWeb -Identity http://sitewebappURL

$spList = $spWeb.Lists[“List Name Here”]

$spList.EventReceivers | Format-List Id, Assembly, Type, Class

#Find the event receivers of ItemAdded and ItemUpdated for the old version (14 if you are on sp2013, 12 if you are on sp2010, so on). Make sure this output spits out the correct receiver you are trying to delete!

$spList.EventReceivers[#]

#Use the following command to delete the old version of the event receiver. Be careful not to delete the wrong one!

$spList.EventReceivers[#].Delete()

$spList.Update()

Then, try the workflow out again, and it should only run once.

Follow

Get every new post delivered to your Inbox.