Friday, April 20, 2018

SharePoint Online: Completely removing an external user

Problem

You are a Global Administrator for your organization's Office 365 subscription, employing both cloud and federated identities. Various site collection administrators look after day-to-day administration of user content site collections.  One site collection administrator manages a site having hundreds of internal (federated) and external (cloud) users.  The site collection is configured to allow both internal and external users to access the site.

The site collection administrator sends an invite to an external user, and the external responds and a cloud account is created for her.  The site collection administrator deletes the account for some reason and sends out another invite, which the external user responds to but experiences an error:
Sorry, something went wrong
We're sorry, sign-in isn't working right now. But we're on it! Please try again later.
In order to recover from the problem, the external user's account must be completely removed from both SharePoint Online and O365.

Solution

  1. Remove user account from all user groups: request the site collection administrator remove the user account from all SharePoint user groups he or she may have added the external user's account to.
  2. Remove the user account from the site collection: request the site collection administrator use this user listing to remove the user completely from the site collection:
    _layouts/15/people.aspx?MembershipGroupId=0
  3. Remove the user profile from SharePoint Online: request the SharePoint Online Admin to remove the user's profile:
    Navigate to: SharePoint Admin Center > user profiles > People > Manage User Profiles
  4. Remove the user's cloud account: as Global Administrator, remove the cloud account:
    Navigate to: Admin Center > Users > Guest users > [click Delete a user button] 

References

Notes

  • Cloud Identity: the identity exists in the cloud in Microsoft Azure Active Directory (MS AAD) and not in your organization's on-premises Active Directory. Also referred to as an external user.
  • Federated Identity: the identity exists in your organization's on-premises Active Directory, which is synchronized with AAD.  Also referred to as an internal user.
  • Global Administrator: has access to all administrative features in the Office 365 suite of services in your organization's Office 365 subscription.  They are the only admins who can assign other admin roles (e.g., SharePoint Admin, Exchange Admin, etc).
  • SharePoint Administrator: effectively the farm administrator, has access to all site collections in the O365 subscription.

Monday, April 16, 2018

SharePoint 2016: Exception of Type Microsoft.Office.SecureStoreService.Server.KeyManagement.InvalidMasterKeyException was thrown

Problem

Connected to a recently deployment development SharePoint 2016 farm to view health report and discovered the following rule violation:
Title The Unattended Service Account Application ID is not specified or has an invalid value.
Severity 2 - Warning
Category Security
Explanation
The Unattended Service Account is a single account that all documents can use to refresh data. It is required when connecting to data sources external to SharePoint, such as SQL. Without a valid Unattended Service Account Application ID, Visio Graphics Services will not be able to refresh Web Drawings that are connected to external data sources. The rule for the Unattended Service Account Application ID failed. The ID does not exist. Visio Graphics Services Application.

Remedy
To resolve this issue, the Visio Graphics Services administrator must provision the Secure Store Service, create a target application, and assign the ID of this target application to this setting. For more information about this rule, see "http://go.microsoft.com/fwlink/?LinkID=142617".
On navigating to the Manage Secure Store page, was presented with error message, Unable to obtain master key:
The lead farm administrator had already created a new master key, so this message shouldn't have been appearing.  I am a farm administrator tasked with preparing the farm in support of upgrade and migration.  Began troubleshooting.

Troubleshooting

  1. Granted farm administrators account Full Control: navigated to the Administrators page of the Secure Store Application, granting my admin account full control of the service application.  This was a test.
    1. Result: same message still displayed.
  2. Attempted to generate new master key via GUI
    1. Result: new message displayed: 
  3. Granted farm administrators account Full Control over connection: navigated to the Permissions page to grant my admin account Full Control over the connection.
    1. Results: same message displayed (as in step 2).
  4. Attempted to generate new master key via PowerShell:
    1. Result: same message displayed, now in shell:
      Update-SPSecureStoreApplicationServerKey : Exception of type 'Microsoft.Office.SecureStoreService.Server.KeyManagement.InvalidMasterKeyException' was thrown. At line:1 char:1 + Update-SPSecureStoreApplicationServerKey -ServiceApplicationProxy $secureStore - ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidData: (Microsoft.Offic...cationServerKey:SPUpdateSPSecur...cationServer Key) [Update-SPSecureStoreApplicationServerKey], SecureStoreServiceException + FullyQualifiedErrorId : Microsoft.Office.SecureStoreService.PowerShellCmdlet.SPUpdateSPSecureStoreApplicationServerKey
  5. Removed and redeployed Secure Store Service Application: removed using PowerShell, then redeployed using PowerShell.
    1. Result: on navigating to the Manage Secure Store page, now presented with the message:
      There are no Secure Store Target Applications in this Secure Store Service Application.  You can create a new Target Application from the Manage Target Applications group in the EDIT Ribbon.
      This message indicated that a new master key could now be generated, and a new Secure Store target application could also be created.

Solution

  • If all fails, rebuild the Secure Store Service Application.

References

SharePoint 2016 TIP: how to change content database name in four steps using PowerShell

On any farm server, open an elevated SharePoint Management Shell.

Execute this commandlet to create a new content database mounted to the same web application hosting the content database you want to rename:
New-SPContentDatabase "[NewDatabaseName]" -DatabaseServer "[Alias or name of database server]" -WebApplication "[Web application URL]"
Execute this commandlet to get the names and, most importantly, IDs of all of the content databases currently mounted to that web application:
Get-SPContentDatabase -WebApplication "[Web application URL]" 
You need those IDs in order to be able to execute this commandlet that performs the actual move operation:
Get-SPSite -ContentDatabase "[OldDatabaseID]" | Move-SPSite -DestinationDatabase "[NewDatabaseID]" 
Perform an IISRESET on all farm servers hosting that web application.  Lastly, dismount the old database from the web application:
Dismount-SPContentDatabase "[OldDatabaseID]"

References

SharePoint 2016: 403 Forbidden Error on Connecting to Site after Move

Problem

Logged onto farm CA server, and then executed the following commandlet to move all site collections in one database to another:
Get-SPSite -ContentDatabase [SourceDatabaseID] | Move-SPSite -DestinationDatabase [DestinationDatabaseID]
followed by an IISRESET. Then tried connecting to the site again to verify that it is operational.  On connecting, experienced a 403 Forbidden error presented in the browser.

Solution 

  • Execute IISRESET on the farm server hosting the content web application.

References

Friday, April 13, 2018

SharePoint 2013: Farm servers removed from farm but continue to appear in farm health reports

Problem

A development farm comprised of two application servers, spapp and spca, and one web front end server, spwfe, needed to have two of its servers removed and their resources used elsewhere (these were VMs), reducing the development farm to a single SharePoint server.  It was decided to keep spwfe and remove spapp and spca.  After Central Administration was moved to spwfe, and spapp and spca removed from the farm, these servers continued to appear in the farm health reports.

Solution

  • Delete the entry from the farm Health Report, and then let the rule be run again as per its normal schedule or manually run the rule.  The removed farm servers will no longer appear.

References

  • Thanks to Waqas Sarwar for the simple tip on how to resolve this issue.