Category: SharePoint 2013

Was trying to troubleshoot an issue with SharePoint groups when I found this. Might be useful in the future so I’m putting it out there.

http://sharepointpromag.com/sharepoint-2013/exploring-sharepoint-users-groups-and-security-using-powershell

Changing service account credentials in SharePoint is always an adventure. You never know whether something’s going to go wrong, leading to an afternoon’s worth of searching for expired credentials, updating them, and hoping that’s the last one. So you can imagine how I felt when I found out that one of our SharePoint instances wasn’t working because the employee who had set it up using his own account (one of those rookie mistakes, I suppose) had left. His account had naturally been disabled and so the SharePoint timer service couldn’t run. Because the farm administrator’s account was disabled Central Administration couldn’t be used to change any managed account credentials as it is inaccessible along with the other SharePoint sites.

In cases like this it is necessary to go back to the days of our friend STSADM. Yes, even though Microsoft has been moving towards PowerShell for many SharePoint command line operations, changing farm credentials is not one of them. On the primary SharePoint (Central Administration) server, run:

stsadm –o updatefarmcredentials –userlogin <DOMAIN\username> –password <password>

On all the other servers in the farm, run:

stsadm –o updatefarmcredentials –userlogin <DOMAIN\username> –password <password> -local

Make sure the “-local” switch is included, otherwise the update commands will conflict.

As is often the case with SharePoint, an iisreset /noforce is necessary.

Now that the farm account was taken care of, it was time to determine what else was broken. Since we now had access to Central Administration it was now possible to change most accounts via Security > Configure Service Accounts. However, attempting to change the Distributed Cache account will lead to the following error message:


Sorry, something went wrong
Distributed Cache Service does not support this operation from Central Administration. Please use Sharepoint Powershell commandlets.


(Ah, Microsoft…one minute you want me to use STSADM and another you want me to use PowerShell…)

Googling this error leads to the following blog post:
https://technet.microsoft.com/en-us/library/jj219613.aspx

There’s a section on this page – Change the Service Account – which tells you what needs to be done, with one exception: the script provided doesn’t have line breaks!

Here is the proper script:

$farm = Get-SPFarm
$cacheService = $farm.Services | where {$_.Name -eq "AppFabricCachingService"}
$accnt = Get-SPManagedAccount -Identity <DOMAIN\username>
$cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$cacheService.ProcessIdentity.ManagedAccount = $accnt
$cacheService.ProcessIdentity.Update()
$cacheService.ProcessIdentity.Deploy()


Run this command as a PowerShell administrator and your Distributed Cache should be back up and running. At least until you discover those other services running under that same account….

Let’s say we have a InfoPath form containing a multiple selection list box.
Because we need to keep track of every selection made in this list box, we choose to “merge” the data from this list box into a column when it is published to SharePoint.  This results in a column in the form library containing entries with concatenated strings (e.g. “Item 1 Item 3…Item 6”).

It isn’t unreasonable to need to find items in this list where a certain item is selected.  Unfortunately how this is done isn’t as straightforward as one might think as there are several pitfalls:

• Were this a regular text column you could create a view that grouped items based on the column.  However, the merged column created by InfoPath is not sortable or filterable.
• You could create a view that filtered all entries that contained the item text that you are looking for.  But you’d have to create a new view for each item in the list.
• URL filtering at the URL level (1) doesn’t work either: this would only show results where the text you are looking for is the ONLY item selected.  For example, if Items 1, 3, and 5 were selected in on entry that entry would not show up since the URL filter is looking for the text “Item 1” and only that text.
• You could tell users to use the search functionality on the list. Though this works it may also present some false results if your entries contain similar data across multiple columns.

So what do we do?  There is a solution, and it involves Web Part filters, which allow users to filter data on a web part based on their input.  To set this up involves a number of steps, so let’s go through them.

1. Create a new (or modify an existing) view in the relevant list.  NOTE: This method only works for standard list views.  It will not work for calendar or Gantt views (if you know of a way to get this to work, please speak up).
2. In the “Filter” section of the edit view page, add a filter for the appropriate column and set the text for the filter to be

   {<variable>}

   where <variable> is a variable name of your choosing.  This text will be substituted for the text that the user provides later on.

3. Save the view, then navigate to it (if applicable).  Click on the gear on the top right hand side of the page (next to your name and before the help button), then select “Edit Page.”
4. You will be placed into an edit view with a one column SharePoint page design.  Click on the “Add a Web Part” link.
5. In the “Categories” section of the resultant ribbon, select the “Filters” folder.  This will present you with a list of Web Parts that can be used as filters for your page.  Select a filter of your choice, then click the “Add” button.
6. Your selected filter will be added to the page.  Some web parts need to be configured; if this is the case, configure it now (click on the web part, then the “Web Part” tab on the ribbon, “Web Part Properties”).
7. Save the changes to your page (“Page” tab in ribbon).
8. Determine the HTML name for the form field that you just added by referring to the HTML code for the page.  For most of the filters this is the text field that contains the text that will be searched for when the filtering is performed.
9. Open the site in SharePoint Designer.  Using the “All Files” folder, navigate to the list that you are editing and look in the “Forms” folder for the view that you are editing.  Open the file.
10. Look for a XML tag block named <ParameterBindings>.  It should contain several <ParameterBinding> tags.  Add another:

    <ParameterBinding Name="<your parametername>" Location="Postback;Connection;Form(<fieldname>);QueryString(<variable>)" />

    <ParameterBinding> is the name that the SharePoint filter is expecting to pass it’s selected value to; <variable> is the name you chose earlier.  These can be same.  <fieldname>is the name of the field you found in step 8 (3), (4).

11. Save the page.
12. Edit the page as you did in step 3.
13. Select the filter web part.  Click on the drop down menu on the top right, then select “Connections > Send Filter Values to > .”  You will be presented with a web page dialog – some web browsers may try to hide this pop up, so you may need to disable pop up blocking on your browser for your SharePoint site if you haven’t already.
14. “Get Parameters” from should be selected by default as the “Connection Type;” if it is not select it.  Click “Configure.”
15. The next page/tab should have the variable name that you created in step 10.  Again, if it is not select it.  Click “Finish.”
16. Congratulations, you’ve set up a linked filter!  Try it out to see if there are any issues that need fixing: if you enter a value in the filter text box and hit enter, the web part below should update with the filtered results.

References

1. https://msdn.microsoft.com/en-us/library/cc751316.aspx
2. https://support.office.com/en-us/article/Work-with-filter-Web-Parts-4d052e5d-c5e9-437b-aa36-ae50b6c2678f
3. https://msdn.microsoft.com/en-us/library/office/ff630170.aspx
4. http://www.sharemuch.com/2014/03/13/how-to-do-advanced-sharepoint-list-view-filtering-with-query-string-paramters/

One of the complaints that often arise out of “SharePoint sprawl” is a lack of consistent navigation: users complain that they don’t know how to get to sites on SharePoint. An obvious fix to this would be to make a “global” navigation menu available to all sites in the farm. Unfortunately, in past versions of SharePoint, this isn’t as easy as it sounds: site collections do not share navigation items. There are various workarounds to this, from Infowise’s Enterprise Capacity Solution to custom site map providers to custom Visual Studio solutions.

Though it’s not the most elegant solution, SharePoint 2013 does provide the possibility of global site navigation out of the box.

To do this, we use a new feature of SharePoint called “Managed Navigation.” Managed Navigation uses the Managed Metadata Service [Term Sets] to generate navigation items for a site. There are a few quirks to this, so let’s go through setting up a simple global navigation structure on a site.

1. In Central Administration, ensure that the “Managed Metadata Service” is running on the “Manage Services on Server” page.
2. From the “Manage service applications” page, click on the “Manage Metadata Service” link, then click on the “Manage” button on the ribbon.
3. Once the Term Store Management Tool opens, click on the drop down on the root of the “Managed Metadata Service” and click on “New Group.” Name the group “Navigation.”
4. Create a new Term Set in the new group, following a similar method (click on the drop down for your new group, click on “New Term Set”).  Name this “Navigation Source.”
5. If desired, change the owner of the new term set (by default it is you; if you are managing as part of a group you can change to that group instead.  Save your changes, then click on the “Intended Use” tab and make sure “Use this Term Set for Site Navigation” is selected while “Available for tagging” is not selected.
6. Now create your terms. These will be the first level navigation items in your new menu.  Click on the drop down for the “Navigation Source” and click on “Create Term.”  Hint: You can create multiple navigation items at once by hitting after each one.
7. For each of the navigation items created in step 6, make sure “Available for tagging” is UNselected on the general tab.  Save your changes, then click on the “Navigation” tab.  In the Navigation Node Section, click on the “Simple Link or Header” radio button and provide an URL to which this navigation item will navigate to (if desired – if you are looking into multi-level menus you can leave it blank; the item can still be a menu but won’t go anywhere when clicked).  NOTE: You can also use the “Term-Driven Page with Friendly URLs” option.  This choice requires that you have tagged the pages that you want on the menu with the proper terms so they show up.  Save your changes.
8. If you only need a single level of navigation, you are done. If you want multi-level navigation, repeat steps 6 and 7 for each sub heading that you want.
9. Next, create a new Term Sets at the “Navigation” level, one for each location (i.e. site collection) that will use this navigation.  Once again, make sure that the term sets are not available for tagging but used as a navigation term set.
10. Click on the drop down menu for one of the new term sets, then choose the “Pin Term With Children” option.  In the resulting dialog box, choose each of the items “Navigation Source” set that you’d previously created (you have to do it for each term).  Repeat for each additional term set that you created in step 9.
    (If you’re wondering why this step is necessary, it’s because SharePoint will only allow you to associate a term set with one site collection.  Creating a new term set and “pinning” the navigation items to the new term set allows you to get past this restriction while ensuring that changes made to the navigation are propagated to sites that rely on the same navigation).
11. Go to the site collection that you would like to change the navigation for.  Under the “Look & Feel” section select “Navigation” (if you do not see this link you may have to turn on the SharePoint Publishing feature for the site).
12. Under either the Global Navigation (for top menu navigation) or Current Navigation (for left side navigation), choose the “Managed Navigation” option.
13. In the “Managed Navigation: Term Set” page, find the term set that you created for this site collection, then click “OK.”
14. Navigate back to the homepage for your site collection.  You should now see the navigation setup you created.
15. Repeat for any other site collection that needs this navigation.

Two posts in one today.

First up is the Quick Launch Menu (the navigation menu on the left). On many websites, you’ll find a navigation structure where there is a heading menu and several submenus underneath those. For example:

• About Us
• Our Menu
  • Appetizers
  • Main Courses
  • Desserts
  • Drinks
• Specials

In many instances, especially where the menu structure can get rather long, the entire menu system is made to be collapsible, so you have to click a heading to expand the menu underneath. In our example, we’d have to click on “Our Menu” to look at the various food options.

Out of the box, SharePoint does not have this functionality. Though you can enable the Publishing infrastructure and utilize it’s Navigation options, this only gets you as far as the menu that we have above: you can click on headings and subheadings but you can’t collapse headings. You can change the master page for the site so that subheadings are flyouts (see http://msdn.microsoft.com/en-us/library/ms466994.aspx), but that’s not what exactly we want. In order to do this, we need to utilize jQuery. The blog entry here has a nice jQuery script that will get you want quickly and easily.

http://borderingdotnet.blogspot.com/2013/04/accordion-left-navigation-for.html

Just put the script within a <script type=”text/javascript”> tag in the master page and add tags to reference jQuery (I recommend using a locally saved copy of jQuery – SharePoint had a knack for mangling externally linked JS files when I tried this) at the bottom of your master page, and you’re all set!

Well, maybe not so fast.

See, in past versions of Microsoft SharePoint Designer, it was easy to open a master page and edit it. That’s not the case in SharePoint 2013. With the introduction of what Microsoft calls Design Manager, Microsoft is trying to move users, especially those who aren’t familiar with behind the scenes coding, away from directly modifying web pages and potentially breaking things. Which is all well and good: dealing with heavily modified SharePoint pages can be a pain in the ass sometimes. Unfortunately the new changes in Design Manager are also a pain in the ass because, by design, the master page isn’t really supposed to be modified. It’s built out of a HTML page by the same name. So how do we do it?

1. Open the site to be modified in SharePoint Designer 2013 and navigate to the Master Pages section.
2. Choose an existing Master Page to edit. Right click the associated HTML page (e.g. Seattle.html or Oslo.html) and choose “copy.”
3. Paste the file into the same directory.
4. Rename this file to a name of your choosing. You’ll be prompted about updating links on the page; choose “Yes” to this dialog.
5. SharePoint will now create a new Master Page using the HTML page and name you’ve chosen.
6. Wait a bit – there are some changes that SharePoint needs to make these files work correctly.
7. You can now edit the new HTML file you copied. If you are looking to add SharePoint ASP objects, you may want to make use of the Snippet Gallery to do it. The Snippet Gallery can be accessed from the link given in the comments at the top of the HTML page. You want to use the Snippet Gallery because the new SharePoint Master Page format utilizes special HTML comments to implement ASP .NET tags (e.g. SPM:<SharePoint:>).
8. Save the file in SharePoint Designer.
9. From the site’s management page, navigate to the Master Page gallery and publish the HTML page (NOTE: You need publishing enabled both at the Site Collection and Site levels).
10. Choose the site’s new format by going to the “Master Page” settings under “Look and Feel.”

If you use the Backup-SPSite PowerShell cmdlet to backup your SharePoint site collection and it fails for whatever reason, you may find that your SharePoint site is locked down in an read-only site. Visitors to the site may see a banner that indicates the site is under maintenance.
In SharePoint 2010 this situation could be remedied by unlocking the site in Central Administration (Application Management > Configure quotas and locks). However, in SharePoint 2013, if this situation occurs, the options to change the lock status will be greyed out.
In order to remedy this situation in SharePoint 2013, you need to change the site’s “Maintenance Mode” flag.

$Admin = new-object Microsoft.SharePoint.Administration.SPSiteAdministration('http://mysite/')
$Admin.ClearMaintenanceMode()

(via http://sharepoint.stackexchange.com/questions/64726/site-collection-locked-stucked-in-read-only-mode)

In some instances, you may deploy a SharePoint environment which is in two different domains and want the SharePoint instance to be able to recognize logins from both domains. This is in fact possible, as long as at least one of the domains has a one way trust with the other domain.

What isn’t obvious is that you can’t do this from the web interface: you do it from the command prompt.

via http://www.pointbeyond.com/2012/06/08/sharepoint-2010-and-one-way-trusts-it-works-fine and other articles, you need to first create an application password:

stsadm –o setapppassword –password <password>

Then, you can add the new forests/domains via:

stsadm –o setproperty –url <url> –pn peoplepicker-searchadforests –pv "domain:<primarydomain>;domain:<secondary>,<domainb>\<serviceaccountusername>,<serviceaccountpassword>"

where is the URL of the web application you want users to be able to access from both domains. The is the domain on which you’ve setup SharePoint (hence the omission of the service account names and passwords).

Proper security practices dictate that passwords should be changed periodically. Unfortunately, for an application like SharePoint, this can also be a major headache.  Since SharePoint 2010, the application has the ability to change passwords automatically on a weekly or monthly schedule, so you don’t have to worry about that account that expired yesterday.  This feature can be accessed from the Central Administration > Security > Configure managed accounts page: for the account that you would like the password to be changed automatically, click on the Edit button and select the appropriate option.  Once the options are set, SharePoint will automatically change the password for that account at the preset time, and update the passwords on services that use that account as appropriate.

This is all well and fine if the password change is successful.  But what if it fails?

It depends on when in the process the failure occurred.  If it failed during the password change you’ll have to figure out what the new password is and update and restart any service that hasn’t been updated yet.  More on that one of these days.

If it failed before the password change, then you may find that your “Configure Managed Accounts” page is broken. Navigating to the page will cause an error.
In this case, you’ll have to disable automatic password changes on that account via the SharePoint PowerShell.

$ma=Get-SPManagedAccount -Identity “\”
$ma
$ma.AutomaticChange=$false
$ma.Update()
$ma

You should now see that automatic password changes have been disabled for this account.  The manage account page should then show up again, which will allow you to retry the process again.

Of course, you could always do it the old fashioned way….