GetSafeOrdinal FATAL ERROR Could not find column LastModifiedTime in PartitionProperties

Migrating from one SharePoint version to another can be harder then it seems at first glance. Thinking through your migration strategy and prerequisites is the first and foremost important step, but no migration is without issues, and no issue is without an error you nor Google has seen before.

In our case this issue happened when migrating from SharePoint 2010 to SharePoint 2013 and upgrading the User Profile Service Application. This caused the error:

GetSafeOrdinal: FATAL ERROR: Could not find column ‘LastModifiedTime’ in PartitionProperties. Please check if the Content and Federated Services farm are of compatible versions.

After rerouting our steps we found out that our customer had ordered and installed a SharePoint .iso in their native language and not in English, where the old SharePoint environment was in English but with a language pack installed in their native language. So where the environment seems Dutch on both versions when using Central Administration, basically these are actually two different languages. Migrating the UPS Sync database from one environment to another caused this error, but recreating the UPS Sync database (and keeping the migrated and upgraded UPS Social and UPS Profile databases) solved this error. All other databases could be migrated and upgraded but this particular one caused a little headache, but nothing is unsolvable – right? 🙂

1

SharePoint Online performance issue caused by deleted term store admin user objects

After working with Microsoft for over a month on a daily basis we found the cause of a serious performance issue within SharePoint Online. This issue affected several enterprise customers of ours.

This issue only occurs on sites which use the “managed navigation” functionality. In SharePoint, you can choose between two navigation methods: structural navigation or managed navigation. Structural navigation is based on site structure. Managed navigation is based on term sets. For further information read this article.

Rootcause symptoms which identify the cause:
When clients initiate a webrequest to the SharePoint Online site it takes 5 to 30 seconds untill the server returns data to the GET method. See this screenshot from Internet Exporer “Profiler”. 

IE_Profiler

Rootcause analysis:
After intensively troubleshooting several tenants we noticed strange behaviour the way the system communicates with the Managed Metadata Service Application. Since the sites are using managed navigation the content will be represented using a managed metadata term set. Because of this configuration EVERY FIRST WEBREQUEST is relies on your defined term sets and its configuration.

Solution:
Allright. Now that we have some understanding how the system relies on the Managed Metadata Service Application when using a managed navigation let’s proceed to implementing the solution.

The reason why the system “waits” for over 15 seconds on this specific part of SharePoint is caused by corrupt or missing user permissions on the database of the Service Application. As we explained “Managed navigation is using term store for its items, every time a request made to the term store, it will try to look for these users which takes some time until the process gives up.  Therefore causes the delay.”

1. Check if there are “present” Term Store Administrators defined in the Office365 portal by going to the SharePoint Admin center.
2. Select “term store” on the left hand side menu.
3. Check if you see any current users defined or SID’s i.e. s-1-5-21-2522053391-2242016340-1337919630-744690. See the image listed below.

Term_store_permissions
4. If you have identified these unknown SID’s on your environment OR identified other non system service-accounts please feel free to remove the permissions to instantly improve performance. 

Now.. if you are using AD FS and DirSync for providing single sign-on access to Office365 services then stick with me. If for instance while developing and building SharePoint solutions several users (developers or admins) have been granted the “Term Set Administrator” permission. At some point the project finishes and their account will be disabled or deleted at the on-premises Active Directory Services. Standard behaviour is that this deletion synchronizes to the cloud with DirSync. This process succesfully deletes the userobject on all front-end systems of Office365 but NOT correctly on all back-end systems in regarding to the Managed Metadata Service Application. In our case the user’s SID was still present on the Managed Metadata SQL database and therefore first webrequests got stuck on this explicit permission.

The only solution for this is contacting Microsoft Support and request them to delete the SID’s and/or old user objects on the database. Once deleted you will instantly notice great performance improvement on your environment!

0

Set Calendar Reviewer rights to all users in Office365

Most companies have policies which permit all users to share their calendars with everyone. There are several PowerShell scripts available online to configure this. However the tricky thing is most enterprises have different Outlook client languages. Because the Outlook client language determines the mailboxfolder attribute to it’s unique language. In this case it is set to the Dutch version “kalender” and the Engilsh version “calendar”.

  1. The fist thing which needs to be done is creating a mail-enabled universal securitygroup on-premises which contains all user objects. Make sure it syncs to Office365 with Windows Azure DirSync.
  2. Once the objects have been succesfully synchronized to the cloud run the script below to determine which language the calendar mailbox folder is:

    $GroupMembers = Get-DistributionGroupMember SG_CalendarReviewer
    $GroupMembers | foreach {
    try
    {
    $isNL = ((Get-MailboxRegionalConfiguration -Identity $_.PrimarySmtpAddress | where {$_.Language -eq “nl-NL”} | Measure).Count -eq 1)
    if ($isNL)
    {
    $identity = $_.PrimarySmtpAddress + “:\Kalender”
    }
    else
    {
    $identity = $_.PrimarySmtpAddress + “:\Calendar”
    }$permission = Get-MailboxFolderPermission -Identity $identity -ErrorAction SilentlyContinue | where {$_.User.toString() -eq “SG_CalendarReviewer”}
    if ($permission)
    {
    write-host “$identity has permission”
    }
    else
    {
    write-warning “$identity doest not have permission”
    } }
    catch
    {

    }
    }

  3. Once you have determined which language the mailboxfolder is for the calendar run this PowerShell script to grant all users in the created securitygroup with the ” Reviewer” on every mailbox belonging to each user object in the securitygroup. The PowerShell script listed below grants the access-right to all English calendars:

    $GroupMembers = Get-DistributionGroupMember SG_CalendarReviewer
    $GroupMembers | foreach {
    $identity = $_.PrimarySmtpAddress + “:\calendar”
    $permissionExists = ((Get-MailboxFolderPermission -Identity john.doe@domain.com:\calendar | where {$_.User.toString() -eq “SG_CalendarReviewer”} | measure).Count -eq 0)
    #Add-MailboxFolderPermission -Identity -User SG_CalendarReviewer -AccessRights Reviewer
    }

  4. Now change the mailboxfolderpermission attribute to the appropiate language and run the last script again.
0

Bypass Spam Filter for Exchange Online in Office365

A common issue several businnesses face is spam. However, sometime companies want to whitelist or either bypass specific domains or users for their e-mail. In this case the request was to accept e-mail from a specific domain for marketing purposes.

The way to configure this in Office365 without having to add an accepted domain is by configuring a transport rule. This can be done by following the below steps:

  1. Login to https://portal.microsoftonline.com.
  2. Select Admin -> Exchange in the top right corner.
  3. Select Mail Flow in the menu on the left.
  4. Click on “Add Rule for Mail Flow” and choose for “Bypass Spam Filtering”.
  5. Select on the “Apply this rule if”  for  “The sender is” “Domain is”
  6. Specify Domain. Add your list of whitelisted Domain.
  7. Select on “Stopm Processsing more rules”
  8. Click Save to save the configuration.
0

Nintex Workflow 2010 issue: Error establishing database connection. SQL Error: 515 VALUE NULL

Today I came across an issue at one or our clients where Nintex Workflow 2010 was up/downgraded. After starting a workflow it threw an correlation ID. After looking up this error in ULS Logging I could find the error message described below:

Error establishing database connection. SQL Error: 515.: System.Data.SqlClient.SqlException: Cannot insert the value NULL into column ‘DatabaseID’, table ‘DEV_Nintex_Workflow4.3.3.dbo.Storage’; column does not allow nulls. INSERT fails.  The statement has been terminated.  at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)   

 at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)    at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)    at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()    at System.Data.SqlClient.SqlDataReader.get_MetaData()    at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)    at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)    at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)    at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)    at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)    at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)    at Nintex.Workflow.Administration.Database.ExecuteReader(SqlCommand command, CommandBehavior behavior) (Build:2330)

The resolution for this issue is related to either a missing Config or Content Database for Nintex. If you look within Central Admin, you actually have to specify the database to use TWICE. This is due to the fact that Nintex has a “Config” and “Content” database – mostly (usually) within the same SQL database.

NintexIssue

0

Remove Active Directory User Accounts Expired Status

Today I came across an issue where one of our clients was not able to get user passwords from expired status. Nearly thousand of their users never login to the on-site company network so don’t ever get the opportunity to change it on site. Since most of the Microsoft products lack the functionality to change it externally – for instance ForeFront products we had to come up with a solution.

When you run the powershell command-let Get-ADUser wo get the properties there is an attribute named -PasswordExpired. Once this attribute is set to “True” you are unable to set it to “False” due to restrictions in Active Directory for security reasons. However there is a way to trick Active Directory by resetting the pwdLastSet atrribute. This attribute is set to the date when the last password change has been executed. This starts a timer which last for the configured period based on your GPO. By resetting the pwdLastSet attribute with this PowerShell script Active Directory will update this attribute with the timestamp the cmd-let has been executed, so it timer starts over again.

This will give the opportunity to your end-users to extend their password expiration term while their off-site. The script is cut in to two steps.

Step 1: Generate a CSV-file with all the AD users and determine their -PasswordExpired status.

Get-ADUser -filter * -properties passwordexpired | sort-object name | select-object Name, passwordexpired | Export-csv -path c:\temp\expired_users.csv -Delimiter “;” -NoTypeInformation

Step 2: Run the PowerShell script to reset te timer of the -pwdLastSet attribute.

Import-CSV -Path c:\temp\expired_users.csv -Delimiter “;” | % {
if ($_.passwordexpired -eq ‘True’)
{
$user = Get-ADUser $_.SamAccountName -properties pwdlastset
$user.pwdlastset = 0

Set-ADUser -Instance $user
$user.pwdlastset = -1

Set-ADUser -instance $user
}
}

0

SharePoint 2010 connection string to determine farmmember status

Today I came across an issue where I had to determine if a server was sucessfully removed from a SharePoint Farm. When starting Central Admin on the application server it launched the Configuration Wizard asking to join or create a new farm. When launching SharePoint Powershell it returned the message “Farm is inaccessible”. The farm consisted out of mutliple application and webservers. Central Admin on one of the applicationservers didn’t list the server which I had to remove so all looked like it was succesfully removed.

However there is a way to know for sure if a server is succesfully removed from a SharePoint Farm. The solution can be found in the registry of the applicationserver. If it is succesfully removed from the farm you will not be able to find the connection string for it’s SharePoint configuration database.

The key can be found in \\HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure where the key will be named ConfigDb. If there is no key listed you can conclude the server has been succesfully removed from the farm. If there is still a key listed feel free to remove it!

0

Unable to apply SharePoint Service-Pack or CU due to a SQL mirrored database

I recently encountered an issue while updating one of our clients SharePoint environments. I came across the following error when applying SharePoint Server 2010 SP2 (14.0.7015.1000). However this issue can occur when updating hotfixes or cumulative updates aswell.

The error which PSCONFIG.EXE generated was:

Performing configuration task 3 of 4
Upgrading SharePoint Products…

100.00%
Failed to upgrade SharePoint Products. An exception of type System.Data.SqlClient.SqlException was thrown. Additional exception information: The operation cannot be performed on database “<SharePoint_UsageAndHealth>” because it is involved in a database mirroring session. 

ALTER DATABASE statement failed.

Total number of configuration settings run: 3
Total number of successful configuration settings: 2
Total number of unsuccessful configuration settings: 1
Successfully stopped the configuration of SharePoint Products.
Configuration of SharePoint Products failed. Configuration must be performed before you use SharePoint Products. For further details, see the diagnostic log l
ocated at D:\Logs\SharePoint\PSCDiagnostics_7_30_2014_15_23_59_204_130559607.log and the application event log.

As the error decribes it is due to a mirroring process on the SQL database. In my case it was the SharePoint Usage and Health service application database. As Microsofts best-practices describe: IT IS NOT RECOMMENDED to mirror the databases for this service applications.

Solution: The way to get past this issue is to BREAK – and not PAUSE – the database mirroring for the databases. Once this is done the SharePoint 2010 Products Configuration Wizard will succeed updating the Farm as designed. Once the update is succesfully applied the mirroring can be rebuild in SQL.

 

0

First post!

Welcome at my blog. On this site you will find technical articles and solutions about various Microsoft products such as:

  • Office 365
  • Exchange Online
  • SharePoint
  • Microsoft SQL Server
  • ADFS and DirSync

Please stay tuned for new blogs to be released very soon!

0

Blog at WordPress.com.

Up ↑