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.

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.

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

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
}
}

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!

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.

 

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!

Blog at WordPress.com.

Up ↑