Tag Archives: Permissions

Powershell, SharePoint 2010, SharePoint 2013

SharePoint Still using old name

So I find this issue comes about a lot of the time for female users, reasons being is when they get married, they take the mans surname. So when their name changes in AD, this doesn’t automatically reflect the same in SharePoint.

When Active Directory Syncs with SharePoint User Profile Service, it also does a sync in parallel with the User Information List (UIL). When new users are added or modified, these users will be added to the UIL. Unfortunately, when user names are changed, this doesn’t always update the UIL and therefore creates a second account for the new updated surname account.

To fix this, we have to merge the accounts together and delete the old one. Without carrying this out, you will probably notice that SharePont still uses your old account which you’ll notice in the top right corner of SharePoint.

So firstly you can check the UIL by going to the url below

http://YOURSITEHERE/_catalogs/users/simple.aspx

Following that, you’ll get a list of users that are in SharePoint, you can also find the users by going to Site Settings, People and Groups. Change the URL at the end to look at MembershipGroupId=0, the full URL can be seen below using my own site.

http://sharepoint-oc/_layouts/15/start.aspx#/_layouts/15/people.aspx?MembershipGroupId=0

From here, you’ll notice two accounts for one user, so we’ll need to merge these using PowerShell and then delete the old.NameChange2

$user = Get-SPUser -Identity “CHIN\MDean” -Web “http://SharePoint-OC/”
Move-SPUser -Identity $user -NewAlias “CHIN\MTravis” -IgnoreSID

The script above moves your old account to the new account with the new surname. Including the permissions that were there.

Once Completed, go to the link below again and delete the old user.

http://sharepoint-oc/_layouts/15/start.aspx#/_layouts/15/people.aspx?MembershipGroupId=0

It might require the user to log out and in for the update however, I’ve seen it just change without needing it sometimes.

SharePoint 2013, Workflows

Reasons for Workflows failing

As I work with workflows I’ll be updating this post as I come across reasons as to why workflows fail to run.


1. Workflow History List Permissions

I’ve recently completed a lengthy approval workflow to which kept failing if an end user created the item, any user in the owners group worked correctly. The users had edit access on the list as well as the tasks list.

I noticed it kept failing at the start of the workflow as I have ‘log to history list’ to help understand where in the workflow I am in case of errors like this, as well as having statuses. I knew for sure users had full edit permissions on the two lists I created however, I didn’t think to check the Workflow History list permissions.

When having ‘log to history list’, users need to be able to edit that list in order for the workflow to log the item to the list which was my issue. I wasn’t using the default members group to group these users, I created my own groups which is why they never had access to that list, giving users access to that list made the approval work as expected.

As the history list is hidden, the easiest way to find this is to type in your SharePoint URL and add /lists/workflow%20history to the end.

https://sharepoint.com/tst/training/lists/workflow%20history

An alternative is to look in SharePoint Designer.
2. TBC

SharePoint 2013

Site Permissions – “Sorry, you don’t have access to this page”

Recently I had an issue where a site owner could not access the Site Permissions, List or Library permissions. This was due to an Owner of the site collection removing the permissions for everyone accidentally and then a site collection admin adding them back in. The downside to this is that the owners group is no longer associated to the Access Requests List. The Access Request setting can be turned on or off, the option for Access Request Settings is then in the ribbon under Site Settings – Site Permissions. The resolution to this is to follow the Microsoft KB article here however, the alternate fix would be to just turn access requests off, although this wouldn’t be everyone’s ideal solution.

The Microsoft KB article is also below should the link ever change.

SOLUTION

To resolve this issue, users must be either site collection administrators or be members of the Owners group for the site. The Owners group must also have permissions to access the Access Requests list. Use the following solutions as appropriate for your specific configuration.

Site collection administrator

If an affected user should be a site collection administrator, go to the following Microsoft website for more information about how to manage administrators for your sites:

Manage administrators for a site collection

Add the user to the Owners group for the site

If the user should be a site owner, you must add the user to the Owners group for the site. To do this, follow these steps:

  1. As a user who can change site permissions, browse to the affected site or site collection. Click the gear icon for the Settings menu, and then click Site settings.
  2. Click Site permissions.
  3. Click the Owners group for the site.
  4. Click New.
  5. In the Share dialog box, enter the user account of the user who you want to add to the group. Then, click Share.
  6. Test to verify that the user can now access the list and approve or decline requests.

Make sure that the Owners group has permissions to the Access Requests list

If the Owners group is changed or was removed from the Access requests list, you must add the Owners group permissions for the list. You must also make sure that the affected user is included in the Owners list. To do this, follow these steps:

  1. As a user who has the Manage Permissions Permission Level on the affected site and who also has access to the Access Requests list (for example, a Site Collection administrator), browse to the Access Requests list in Internet Explorer.
  2. Press F12 to open the F12 Developer Tools window.
  3. Click the Network tab, and then press F5 to enable network traffic capturing.
  4. Refresh the Access Requests page in Internet Explorer. After the page has loaded, press Shift+F5 to stop capturing network traffic.
  5. In the Developer Tools window, double-click the first result in the URL list. This URL ends in “pendingreq.aspx.”
  6. In the Developer Tools window, click Request body.
  7. In the search box, type pagelistid:, and then press Enter.Note The search highlights the pageListId text.
  8. Copy the GUID that follows the pageListId. The GUID will be between an opening brace ( { ) character and a closing brace ( } ) character as follows:
    {GUID}

    Note Include the opening and closing brace characters when you copy the GUID. This GUID is the identifier for the SharePoint Online Access Requests list for your organization.

  9. In the browser address bar, enter https://<URL<URL of affected site or site collection>/_layouts/15/ListEdit.aspx?List=<{GUID}>, and then press Enter.Note In this address, <URL of affected site or site collection> represents the URL for the site collection in which you want to change the access requests (for example, https://contoso.sharepoint.com). And <{GUID}> represents the GUID that you copied in step 8.
  10. On the Settings page, click Permissions for this list.
  11. Make sure that the Owners group for the site is included in the list of permissions for the Access Requests list. If the Owners group for the site collection does not exist, click Grant Permissions, enter the name of the Owners group for the site in the Share dialog box, and then click Share.
  12. Follow the steps in the “Add the user to the Owners group for the site” section to make sure that the user is included in the Owners group.