• Office 365 Security and Compliance Center Portal
• Using Office 365 Management Activity API in your custom application/service/script.
• Using the PowerShell command Search-UnifiedAuditLog

Using Search-UnifiedAuditLog - The Challenges

• You cannot guarantee how many records the command will return in a single call even when you have specified the ResultSize. You should repeatedly call Search-UnifiedAuditLog in a loop using the same value for SessionId parameter until records stop getting returned.
• The maximum number of records that you can retrieve for a given criteria and SessionId is 50,000. That too when you use the ReturnLargeSet option for the SessionCommand parameter. If you find that the value for ResultCount in the returned data is greater than 50,000, that means you're not going to be able to retrieve all records in the current session and you should narrow your search to ensure the ResultCount stays below 50,000.  Remember that you have to issue multiple calls to Search-UnifiedAuditLog in a loop using the same SessionId to retrieve all 50,000 records.
• If you have a slow connection, and it's taking a long time to retrieve the data, your session may time out on the server and in that case, you will see that the value for ResultIndex is getting reset to 1 before you could retrieve all data that matched the criteria specified.
• When you are using repeated calls to Search-UnifiedAuditLog to retrieve data, you may get a few calls that return 0 results due to a network glitch, and your script may be "fooled" into believing that all data has been retrieved.

The Solution - An Intelligent Script

• The script will log it's progress in a log file
• The output will be saved in a CSV file
• if you see the following message in the log file, that would indicate you need to adjust the configurable variables to ensure each interval is not returning more than the maximum limit: "WARNING: x total records match the search criteria. Some records may get missed. Consider reducing the time interval!"

Note: You will need the SharePoint Online Client Components SDK to run the script.

How does it work?

tp_ExternalToken Explained

$cs = [Microsoft.Sharepoint.Administration.SPWebService]::ContentService 
$cs.TokenTimeout = (New-TimeSpan -minutes 1440) 
$cs.Update() 

Common Problems with tp_ExternalToken Refresh

$w = Get-SPWebApplication $url 
$w.PeoplePickerSettings.ClaimsAuthRoleProviderUsesGlobalCatalog = $true 
$w.Update()

Problem #4: SharePoint tries to enumerate user groups using the Windows API GetAuthorizationGroups. This API has known issues including one that results in this API call to fail if one of the groups that the user is a member of has SID history attached to it. You may see the following errors in the ULS logs:

System.InvalidOperationException: The server is unwilling to process the request.

System.DirectoryServices.DirectoryServicesCOMException: There is no such object on the server

Resolution: We can force SharePoint to use the "soft" SID resolution method which does not involve a call to GetAuthorizationGroups. This can be done by identifying an account in each domain that is a member of Windows Authorization Access group in that domain. Once the accounts have been identified, we need to set ClaimsAuthRoleProviderUsesGlobalCatalog property to $true as mentioned in Resolution #3 and then configure the people picker settings with a username and password for each domain. Every single domain from which users can be added to SharePoint must be specified or that domain will not be searched.

stsadm -o setproperty -pn peoplepicker-searchadforests -pv "domain:domain1.fqdn.com,account,Password;domain:domain2.fqdn.com,account,Password" -url http://webapp

Be sure to run setapppassword on each server in the farm so that password can be encrypted.

Happy SharePointing!

1. We had to use a “specific-location” retention policy instead of an org-wide policy. As documented here, a location-specific policy can only contain 100 SharePoint/OneDrive sites. The number of users with retention hold could be several hundred so a single policy wouldn’t be enough to hold all the sites. The script had to be intelligent enough to dynamically create new policies if no empty “slots” were found in the existing policies. I mention “slots” here since we could have a situation where a policy was previously full which could have resulted in creation of new policies, however, some users in that policy had their hold released afterwards and now the policy has empty “slots” which should be reused.
2. We had to dynamically determine the user’s OneDrive for Business site Url in Office 365 based on the user object in Active Directory. One approach that we could have used is documented here. However, this approach wouldn’t work if let’s say the script was run after the user’s profile had been marked for deletion because they have left the company, but the user’s OneDrive site was still not deleted as there is a default 30-day retention period, and there was a requirement to place an indefinite retention hold on that site. See this article to learn more about the default preservation/retention for OneDrive for Business sites. To address this challenge, I decided to use the user’s UPN which is also stored in the on-premise Active Directory to determine their OneDrive site dynamically. This is not the best approach, as it’s not very reliable, but this was the best one we could use.

############################## Begin Configuration #####################################################
#The logFileLocation is a folder where logs will be created and it must already exist
$logFileLocation = "C:\RetentionLogs" 
#The Url of the SPO Service for this tenant
$spoTenant = "https://therazas-admin.sharepoint.com"
#OneDrive site root
$odbSiteRoot = "https://therazas-my.sharepoint.com/personal"
#The UPN of the tenant admin
$tenantAdmin = "admin@therazas.onmicrosoft.com"
#The encrypted password will be stored here. If we don't find the file, we will simply prompt for password and save it here
$passwordFile = [System.Environment]::GetFolderPath('ApplicationData') + "\AdminPassword.txt"
#The Complaince center connection Uri. This won't need to be changed in most cases and its global
$complainceCenterUri = "https://ps.compliance.protection.outlook.com/powershell-liveid/"
#Name of the preservation policy
$policyName = "test"
#Maximum sites per policy
$MaxSitesPerPolicy = 100
#The AD search root for users
$searchRoot = "LDAP://dc=tmr,dc=com"
#Attribute Name that we will query AD for
$attributeName = "extensionAttribute13"
#Value of attributeName that will put the ODB Site on hold
$litigationHoldValue = "DONOTPURGE"
############################## End Configuration #####################################################

1. Write-LogFile: A function that simply logs messages in a log file for troubleshooting and understanding of what the script is doing.
2. Retrieve-Credentials: Saves/retrieves the password for the $tenantAdmin account to/from an encrypted file on the local computer. The file is stored at the $passwordFile path.
3. Ensure-Policies: This function is responsible for creating additional retention policies if needed to ensure that one policy does not contain more than 100 sites. The new policies will be based on on the initial policy name defined in $policyName variable. The new policies will have a number attached to them (1, 2, 3… and so on).
4. Get-SitesInPolicy: Returns all sites that are added to one of the preservation policies. We have to retrieve this information to determine which users should have their retention hold released if the attribute has been cleared.
5. Add-SiteToPolicy: Finds an open “slot” in the policies that exist and adds the site to the first available slot.
6. Remove-SiteFromPolicy: Removes the specified site from the policy. There could be multiple policies to check so we loop through each policy until we find the site.

Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChecking

############################## Begin Configuration #####################################################
#The logFileLocation is a folder where logs will be created and it must already exist
$logFileLocation = "C:\RetentionLogs" 
#The Url of the SPO Service for this tenant
$spoTenant = "https://therazas-admin.sharepoint.com"
#OneDrive site root
$odbSiteRoot = "https://therazas-my.sharepoint.com/personal"
#The UPN of the tenant admin
$tenantAdmin = "admin@therazas.onmicrosoft.com"
#The encrypted password will be stored here. If we don't find the file, we will simply prompt for password and save it here
$passwordFile = [System.Environment]::GetFolderPath('ApplicationData') + "\AdminPassword.txt"
#The Complaince center connection Uri. This won't need to be changed in most cases and its global
$complainceCenterUri = "https://ps.compliance.protection.outlook.com/powershell-liveid/"
#Name of the preservation policy
$policyName = "test"
#Maximum sites per policy
$MaxSitesPerPolicy = 100
#The AD search root for users
$searchRoot = "LDAP://dc=tmr,dc=com"
#Attribute Name that we will query AD for
$attributeName = "extensionAttribute13"
#Value of attributeName that will put the ODB Site on hold
$litigationHoldValue = "DONOTPURGE"
############################## End Configuration #####################################################
$Session = $null
#Logs the desired message to the log file location
Function Write-LogFile ([String]$Message)
{
	$Message = "[" + [DateTime]::Now.ToString() + "] " + $Message
	if (Test-Path $logFileLocation)
	{
		$fileName = $logFileLocation + "\" +  [DateTime]::Now.ToShortDateString().Replace("/", "_") + ".txt"
		$Message | Out-File $fileName -Append -Force
	}
	else
	{
		$errorM = "Log File Location " + $logFileLocation + " not found..."
		Write-Output $errorM
		Write-Output $Message
	}
}

Function Retrieve-Credentials ([Boolean]$SPO=$false)
{
	   if (Test-Path $passwordFile)
      {
            $securePassword = Get-Content -Path $passwordFile | ConvertTo-SecureString
      }
      else
      {
            $securePassword = Read-Host -Prompt "Enter password" -AsSecureString
            $securePassword | ConvertFrom-SecureString | Out-File -FilePath $passwordFile -Force
      }
	  if ($SPO -eq $true)
	  {
	  	$creds = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($tenantAdmin, $securePassword)
	  }
	  else
	  {
	  	$creds = New-Object System.Management.Automation.PSCredential($tenantAdmin, $securePassword)
	  }
	  return $creds
}

#This function accepts $TotalSites as a parameter which is the total number of sites in the environment that have a preservation hold for ODB sites
Function Ensure-Policies ([Int]$TotalSites)
{
	$currentPolicyName = $policyName
	[Int]$reqNumber = $TotalSites/$MaxSitesPerPolicy
	if ($TotalSites%$MaxSitesPerPolicy -eq 0)
	{
		$reqNumber = $reqNumber - 1
	}
	#Let's make sure the "base" policy exists to avoid unintentional policy creation. This will throw an exception if policy does not exist
	$policy = $null
	try
	{
		$policy = Get-RetentionCompliancePolicy -Identity $policyName
	}
	catch
	{
		$policy = $null
	}
	if ($policy -eq $null)
	{
		throw [System.InvalidOperationException] "Complaince policy $policyName does not exist. Please check the name and try again."
	}
	#We need to ensure that we have $reqNumber of polcies created with the naming format $policyName1, $policyName2 and so on...
	for($i = 1; $i -le $reqNumber; $i++)
	{
		$currentPolicyName = $policyName + $i
		$policy = $null
		try
		{
			$policy = Get-RetentionCompliancePolicy -Identity $currentPolicyName
		}
		catch
		{
			$policy = $null
		}
		if ($policy -eq $null)
		{
			#This means the policy does not exist. We need to create it
			$message = "Creating preservation policy $currentPolicyName with indefinite hold..."
			Write-LogFile $message
			$policy = New-RetentionCompliancePolicy -Name $currentPolicyName
			$rule = New-RetentionComplianceRule -Name "Indefinite Hold for $currentPolicyName" -Policy $currentPolicyName -PreservationDuration Unlimited
		}
	}
}

#Returns an ArrayList of all sites in preservation policies)
Function Get-SitesInPolicy
{
	$sitesList = New-Object System.Collections.ArrayList
	$currentPolicyName = $policyName
	$i = 0
	while ($true)
	{
		$policy = $null
		try
		{
			$policy = Get-RetentionCompliancePolicy -Identity $currentPolicyName
		}
		catch
		{
			$policy = $null
		}
		if ($policy -eq $null)
		{
			break
		}
		foreach ($location in $policy.SharePointLocation)
		{
			$x = $sitesList.Add($location.Name)
		}
		$i = $i + 1
		$currentPolicyName = $policyName + $i
	}
	return ,$sitesList
}

#Adds the specified site to an availalbe "slot" in the policies. 
Function Add-SiteToPolicy ([String]$SiteUrl)
{
	$currentPolicyName = $policyName
	$i = 0
	while ($true)
	{
		$policy = Get-RetentionCompliancePolicy -Identity $currentPolicyName
		if ($policy.SharePointLocation.Count -lt $MaxSitesPerPolicy)
		{
			$message = "Adding site " + $SiteUrl + " to the preservation policy " + $currentPolicyName
			Write-LogFile $message
			Set-RetentionCompliancePolicy -Identity $currentPolicyName -AddSharePointLocation $SiteUrl
			break
		}
		$i = $i + 1
		$currentPolicyName = $policyName + $i
	}
}

#Removes the specified site from the list of policies
Function Remove-SiteFromPolicy ([String]$SiteUrl)
{
	$currentPolicyName = $policyName
	$i = 0
	while ($true)
	{
		$policy = Get-RetentionCompliancePolicy -Identity $currentPolicyName
		foreach ($location in $policy.SharePointLocation)
		{
			if ($location.Name.Equals($SiteUrl))
			{
				$message = "Removing site " + $SiteUrl + " from the policy " + $currentPolicyName
				Write-LogFile $message
				Set-RetentionCompliancePolicy -Identity $currentPolicyName -RemoveSharePointLocation $SiteUrl
				return
			}
		}
		$i = $i + 1
		$currentPolicyName = $policyName + $i
	}
}
#Query the AD
try
{
	$old_ErrorActionPreference = $ErrorActionPreference
	$ErrorActionPreference = 'Stop'
	Write-LogFile "******************************Starting Script Execution******************************"
	$message = "Querying Active Directory for accounts on legal hold at path " + $searchRoot
	Write-LogFile $message
	$objOU = New-Object System.DirectoryServices.DirectoryEntry($searchRoot)
	$strFilter = "(&(objectCategory=User)("+$attributeName+"=" + $litigationHoldValue + "))"
	$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
	$objSearcher.SearchRoot = $objOU
	$objSearcher.PageSize = 1000
	$objSearcher.Filter = $strFilter
	$objSearcher.SearchScope = "Subtree"
	$colProplist = "userPrincipalName"
	foreach ($i in $colPropList){$x = $objSearcher.PropertiesToLoad.Add($i)}
	$colResults = $objSearcher.FindAll()
	$message = "Found " + $colResults.Count + " result(s) from the AD search query"
	Write-LogFile $message
	$message = "Connecting to SPO service at url " + $spoTenant + " for validating ODB Sites" 
	Write-LogFile $message
	$creds = Retrieve-Credentials
	Connect-SPOService -Url $spoTenant -Credential $creds
	$userTable = New-Object System.Collections.Hashtable($colResults.Count)
	foreach ($objResult in $colResults)
	{
		#Updated 4/15 to handle the null UPN scenario
		$upnValue = $objResult.Properties["userPrincipalName"][0]
		if ($upnValue -eq $null)
		{
			#User does not have UPN Set. Continue
			Write-LogFile "Found user without UPN set. Skipping..."
			continue
		}
		$upn = $upnValue.ToString() 
		#Calculate the ODB Site Url
		$odbSite = $upn.Replace("@", "_")
		$odbSite = $odbSite.Replace(".", "_")
		$odbSite = $odbSite.Replace("-", "_")
		$odbSite = $odbSiteRoot + "/" + $odbSite
		$message = "Checking if ODB site for user " + $upn + " exists at " + $odbSite
		Write-LogFile $message
		try
		{
			$site = Get-SPOSite $odbSite
		}
		catch
		{
			$site = $null
		}
		if ($site -eq $null)
		{
			Write-LogFile "Site Not Found, Skipping this user..."
			continue
		}
		Write-LogFile "Site Found!"
		$userTable.Add($upn, $odbSite)
	}
	#$userTable now contains all users with valid ODB Sites. 
	#Let's make sure we have the required number of policies created (1 Policy = 100 sites)
	#Connect to the complaince center
	$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $complainceCenterUri -Credential $creds -Authentication Basic -AllowRedirection -WarningAction Ignore
	$x = Import-PSSession $Session
	Ensure-Policies -TotalSites $userTable.Count 
	#Next, we need to remove all ODB Sites that are already in the preservation policy
	$sitesList = Get-SitesInPolicy
	#Now lets determine which sites we need to add to policy
	$allUsers = $userTable.Keys.GetEnumerator()
	$addCount = 0
	while ($allUsers.MoveNext())
	{
		$currentUser = $allusers.Current
		$currentSite = $userTable[$currentUser]
		#Check if this site is already in the policy
		if ($sitesList.Contains($currentSite))
		{
			$message = "ODB Site for user " + $currentUser + " is already in the preservation policy. Skipping"
			Write-LogFile $message
			#Remove this site from the list so we can release the hold on the remaining sites
			$sitesList.Remove($currentSite)
		}
		else
		{
			try
			{
				Add-SiteToPolicy -SiteUrl $currentSite
				#Set-RetentionCompliancePolicy -Identity $policyName -AddSharePointLocation $currentSite
				$addCount = $addCount + 1
			}
			catch
			{
				Write-LogFile "Error Ocurred while adding site to policy." 
				Write-LogFile $_.Exception.Message
			}
		}
	}
	$message = "Sucessfully Added " + $addCount + " site(s) to the preservation policy"
	Write-LogFile $message
	#Now let's remove the sites from the hold. Everything left in $sitesList needs to be removed. The user either does not exist in AD or does not has $litigationHoldValue set.
	$removeCount = 0
	foreach ($siteUrl in $sitesList)
	{
		try
		{
			#Set-RetentionCompliancePolicy -Identity $policyName -RemoveSharePointLocation $siteUrl
			Remove-SiteFromPolicy -SiteUrl $siteUrl
			$removeCount = $removeCount + 1
		}
		catch
		{
			Write-LogFile "Error Ocurred while removing site from policy." 
			Write-LogFile $_.Exception.Message
		}
	}
	$message = "Sucessfully Removed " + $removeCount + " site(s) from the preservation policy"
	Write-LogFile $message
	Write-LogFile "******************************Ending Script Execution******************************"
}
catch 
{
	Write-LogFile "Error Ocurred." 
	Write-LogFile $_.Exception.Message
	#Updated 4/15 to handle the null UPN scenario
	Write-LogFile $_.ScriptStackTrace

}
finally
{
	#Clear the complaince center session
	if ($Session -ne $null)
	{
		Remove-PSSession $Session
	}
	$ErrorActionPreference = $old_ErrorActionPreference
}

The Problem

The August 2015 Cumulative Update for SharePoint 2013 was released earlier this month as mentioned in Stefan’s Goßner’s blog post here. The installation of the August 2015 Cumulative Update server package may fail with the following error:

“The installation of this package failed”

The error above is a generic error and can occur due to a variety of different reasons such as low disk space, incorrect package download etc. However, for the August 2015 Public Update we have received several reports over the past few days of this issue occurring on multiple machines. In all these occurrences, the root cause of the package installation failure was found to be the following messages in the latest modified MSP log file (e.g. wssmui-en-us_MSPLOG.LOG, but the actual file name in your case could be different depending on which package failed to install) located in the temp folder of the server where you are installing the package (by default, it is C:\Users\username\AppData\Local\Temp\2):

CAQuietExec:  Error 0x8007000d: CAQuietExec Failed

CustomAction RegisterPerfmonManifest returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

The Workaround

The best workaround for this issue is to simply run the installation package 3 times. The package will fail to install with the above error on the first two attempts, but should be successful on the third attempt.  The installation will not be corrupt and there are no other known issues once you have the update package successfully installed.

Note: A previous version of this blog post mentioned a registry key workaround which is not as effective as originally thought. If the installation package continues to fail with the error mentioned above even after the 3rd attempt, please let me know.

The Root Cause

The issue was being caused due to an error while registering a new Performance Counter within the SharePoint Search sub-system.

The Solution

The issue has been fixed with the September 2015 Server/Uber packages for SharePoint 2013 which were released last night (9/16/2015). If you haven’t already installed the August 2015 Server/Uber package, you may install the September 2015 Uber/Server package in your farm which includes all updates since SP1 and also has the package installation issue fixed. Please note that you must already have SharePoint Server 2013 Service Pack 1 installed before installing this package. The relevant full server packages (aka Uber packages) can be downloaded at the links below:

• Download SharePoint Foundation 2013 September 2015 CU
• Download SharePoint Server 2013 September 2015 CU
• Download Project Server 2013 September 2015 CU

Apple recently released a new version of Safari for MAC computers. The browser version is 7.1. The browser might be great, but SharePoint 2010 as well as MOSS 2007 all of a sudden have a number of User Interface issues including but not limited to:

1. SharePoint navigation menus not functioning correctly
2. SharePoint ribbon menu options being disabled for all users
3. SharePoint People picker appears to hang when searching for a user

The Cause

I have to be honest, there is nothing wrong with the new browser. As you may already know, SharePoint 2010 and MOSS 2007 are just web applications that are based on ASP.NET 2.0. The root cause of this issue lies at the ASP.NET layer and can affect any ASP.NET 2.0 web application. The issue does not exist in ASP.NET 4.0 and as a result, SharePoint 2013 is not impacted by this problem.

ASP.NET reads the user agent of the incoming request, and using regular expressions, assigns a Browser ID to the incoming request. ASP.NET uses browser definition files to assign browser IDs. The browser IDs are then used to enable or disable “capabilities” such as AJAX, certain types of controls etc. Applications such as SharePoint also use the browser ID to change the way they render content to achieve the best user experience.  These browser definition files are located by default at Drive:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\Browsers. The user agent for Safari 6.0 contained AppleWebKit/536.26 and ASP.NET was assigning the browser ID "Safari1Plus" to this and other recent Safari browsers based on the following entry in Mozilla.browser:

   1: <browser id="Safari1Plus" parentID="Safari">

   2:        <identification>

   3:            <capability name="appleWebTechnologyVersion" match="\d\d\d" />

   4:        </identification>

   5:        <capture>

   6:        </capture>

   7:        <capabilities>

   8:            <capability name="ecmascriptversion"       value="1.4" />

   9:            <capability name="w3cdomversion"           value="1.0" />

  10:            <capability name="supportsCallback"        value="true" />

  11:        </capabilities>

  12: </browser>

Notice how the regular expression “\d\d\d” on line 3 results in a match for 536.26 and as a result, a browser ID of “Safari1Plus” gets assigned to requests with this user agent. SharePoint 2010, rightly so, assumes that the latest version of Safari would have the ID “Safari1Plus”.

Several years ago, there used to be a Safari browser that had AppleWebKit/60 in the user agent string. ASP.NET uses the browser ID “Safari60” for these browsers and does not enable AJAX since the browser is so old. Here is the entry in Mozilla.browser that was added for these old Safari browsers:

   1: <browser id="Safari60" parentID="Safari">

   2:        <identification>

   3:            <capability name="appleWebTechnologyVersion" match="60" />

   4:        </identification>

   5:        <capture>

   6:        </capture>

   7:        <capabilities>

   8:            <capability name="ecmascriptversion"       value="1.0" />

   9:        </capabilities>

  10:  </browser>

The problem is that Safari 7.1 has AppleWebKit/600.1.17 in the user agent string and as a result, it ends up getting matched with the Safari60 definition. The regular expression here (line 3 in the snippet above) should have been ^60$ to avoid a match for 600. Because the BrowserId is incorrectly detected as Safari60, SharePoint does not enable the Menu controls for this browser Id. Also, due to a missing supportsCallback attribute in the browser definition file, AJAX calls do not function correctly which SharePoint uses when working with Ribbons and the people picker.

The Solution

Update : A permanent fix for this issue was released with the March 2015 Public Update for SharePoint 2010. If you install this or a later update, you will not need to apply the workaround mentioned below. I highly recommend upgrading your environment to the latest version instead of relying on the manual workaround. However, if you cannot immediately upgrade, you may use the workaround temporarily.

The ideal solution would be to update the Mozilla.browser file located at Drive:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\Browsers with correct regular expressions (^60$ for Safari60 and ^85$ for Safari85) and then run aspnet_regbrowsers.exe –i to re-deploy the browser definitions to all applications. However, strictly speaking, Mozilla.browser file is a system file that may get updated by a future Microsoft update and overwrite your changes. Keeping that in mind, the best solution would be to create a new browser definition file in the local IIS virtual directory for the affected SharePoint web applications. Here are the steps that you can use to apply this solution:

1. Inside the App_Browsers folder for your SharePoint web application (usually located at Drive:\inetpub\wwwroot\wss\VirtualDirectories\port\App_Browsers), create a new text file named safari.browser (Please ensure it is not safari.browser.txt, .browser must be the extension of the file)
2. Add the following text to the file:

      1: <?xml version="1.0" encoding="utf-8" ?>

      2: <browsers>

      3:   <browser id="Safari6xxFix" parentID="Safari60">

      4:     <identification>

      5:       <capability name="appleWebTechnologyVersion" match="60\d" />

      6:     </identification>

      7:     <capture>

      8:     </capture>

      9:     <capabilities>

     10:        <capability name="ecmascriptversion"       value="1.4" />

     11:        <capability name="w3cdomversion"           value="1.0" />

     12:        <capability name="supportsCallback"        value="true" />

     13:     </capabilities>

     14:     <controlAdapters>

     15:       <adapter controlType="System.Web.UI.WebControls.Menu"

     16:                adapterType="" />

     17:     </controlAdapters>

     18:   </browser>

     19: </browsers>

3. Save and close the file
4. Verify that the issues are now resolved.

IMPORTANT: You must do a “dummy edit” on the compat.browser file located in the App_Browsers folder of your web application to force a recompilation of the browser definition files and for the solution to take effect. Simply open the compat.browser file and add a space at the very end of the file and save it back. You can remove the space and save it again if you wish, but an edit to compat.browser should force the recompilation.

Hope this helps. Happy SharePointing!!!

In SharePoint 2007/2010, if you have a document library that contains lookup columns that were programmatically created or created via a custom feature, you may run into a problem where when a user clicks on a document to open the document, the document gets opened in Office Client (MS Word or MS Excel) but the Document Information Panel (DIP) that shows the document metadata fails to load and the following error is displayed on the user’s screen:

DIP Error when opening a word document from a document library in SharePoint

Error Message: The Document Information Panel was unable to load. The document will continue to open . For more information, contact your system administrator.

Error Details: The form cannot be opened. To fix this problem, contact the form designer.
Form template: http://servername/sites/dip/proppanel.xsn 
The following DataObject either cannot be created or cannot be initialized: list_5433DC30-D758-4B56-A4CA-9CCD98716342
Document Information Panel cannot add the following object to the DataObjects collection: list_5433DC30-D758-4B56-A4CA-9CCD98716342
list_5433DC30-D758-4B56-A4CA-9CCD98716342 could not be added to the DataObjects collection.
The following item already exists in the collection: list_5433DC30-D758-4B56-A4CA-9CCD98716342

The Cause
This problem is caused if your list contains lookup columns that were created programmatically or using custom features. If the GUIDs of the list and column being referenced are not enclosed in curly brackets “{ }“ in the schema of the columns/fields, you will have this problem when opening the documents in Office Client applications.

The Solution

There was a forum discussion on one of the MSDN forums here where someone had found the problem and posted some code to fix it. I figured the code is not the easiest to use, especially since you have to compile it to run and make some changes depending on the environment. I have created a PowerShell equivalent of the code and have modified it to make it more generic. All you need to do is change the Url to the url of the site/sub-site where the document library having the problem is located and the name of the document library (variables $siteUrl and $listName). Once you run this script against the library having the problem, you should be able to open documents from the library and have the DIP loaded without any issues.

Disclaimer: The following script is a sample only and has not been tested fully. Please test this script in a test environment before applying on a production system. Provided “as is” without warranties

Add-PSSnapin Microsoft.SharePoint.PowerShell
$siteUrl = http://servername/sites/dip
$listName = "Documents"
$web = Get-SPWeb $siteUrl
$list = $web.Lists | where {$_.Title -eq $listName}
$fields = $list.Fields | where {$_.Type -eq "Lookup"}
foreach ($field in $fields)
{
Write-Host "Fixing Field "$field.Title
#Fix the Lookup WebId first
$lookupWeb = $field.LookupWebId
$tempSchema = $field.SchemaXml
$toFind = "WebId=`"$($lookupWeb)`""
$toReplace = "WebId=`"{$($lookupWeb)}`""
$tempSchema = $tempSchema.Replace($toFind, $toReplace)
  #Check if we need to fix the Lookup List Id too
if ($field.LookupList.Length -gt 0)
{
  $lookupList = $field.LookupList
  #Need to make sure we don't do a double fix
  if ($lookupList.Contains("{") -eq $false)
  {
   $toFind = "List=`"$($lookupList)`""
   $toReplace = "List=`"{$($lookupList)}`""
   $tempSchema = $tempSchema.Replace($toFind, $toReplace)
  }
}
#Schema updates complete at this point. Replace the field schema
$field.SchemaXml = $tempSchema
$field.Update()
Write-Host "Done Fixing "$field.Title
}

Hope this helps! Happy SharePointing!

Overview

I have recently come across an annoying problem, and I have seen it often enough that I decided to blog about it. Consider the following scenario:

You open your SharePoint Central Administration Website and it takes a long time to load the first time. After the initial load, the site is responsive and pages load and open fast. If you are experiencing these symptoms, you have come to the right place. Continue reading!

Why is it Slow?

In the process of initializing the SharePoint Central Administration website, SharePoint tries to find the security group IIS_WPG. It first checks the local computer for the group, if the group is not a local security group, SharePoint tries to find the group on the domain. If you have a lot of two-way trusts, this search can go on for several minutes, which is what causes the slowness when loading the site.

IIS_WPG: Do I really need it?

Why does SharePoint need IIS_WPG – that’s a different topic. This group used to be a local security group on the default installation of IIS 6 (Windows Server 2003) and SharePoint 2007 (MOSS) would add the SharePoint application pool accounts to this group. I don’t know what problems you will run into if you delete the IIS_WPG group in MOSS 2007/WSS 3.0, but you should definitely not delete it.

The IIS_WPG local security group in Windows Server 2003

The group went away with IIS7/Windows Server 2008, but SharePoint still tries to find it, which is what creates the slowness. This behavior is same for both MOSS 2007/WSS 3.0 and SharePoint 2010

The Solution

The solution in this case is simple. All you need to do is create a local security group named “IIS_WPG” on each SharePoint server in the farm, and after that, central administration web site should load without any delays.

Happy SharePointing!

If you are looking at a System.Net.IPAddress object in a memory dump in WinDbg and are wondering what I.P. address it actually represents, this post explains how you can get that information nice and quick.

The Details

I was looking at a hang dump today where a custom HTTP module was trying to connect to a remote server and was timing out. I found the System.Net.IPAddress on the stack using !dso and here is what the object looks like :

0:024> !do 0ae055a8
Name: System.Net.IPAddress
MethodTable: 7a77385c
EEClass: 7a773750
Size: 40(0x28) bytes
GC Generation: 0
(C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
790fc054  40020d7        4         System.Int64  1 instance 552882186 m_Address
790f97f0  40020d8       14        System.String  0 instance 00000000 m_ToString
7a7740c0  40020dc       1c         System.Int32  1 instance        2 m_Family
7912b058  40020dd       18      System.UInt16[]  0 instance 0ae055d0 m_Numbers
790fc054  40020de        c         System.Int64  1 instance 0 m_ScopeId
790fe200  40020df       20         System.Int32  1 instance        0 m_HashCode
7a77385c  40020d3      7bc System.Net.IPAddress  0   shared   static Any
    >> Domain:Value  000d0548:NotInit  1bea0890:06daefc8 <<
7a77385c  40020d4      7c0 System.Net.IPAddress  0   shared   static Loopback
    >> Domain:Value  000d0548:NotInit  1bea0890:06daf00c <<
7a77385c  40020d5      7c4 System.Net.IPAddress  0   shared   static Broadcast
    >> Domain:Value  000d0548:NotInit  1bea0890:06daf050 <<
7a77385c  40020d6      7c8 System.Net.IPAddress  0   shared   static None
    >> Domain:Value  000d0548:NotInit  1bea0890:06daf050 <<
7a77385c  40020d9      7cc System.Net.IPAddress  0   shared   static IPv6Any
    >> Domain:Value  000d0548:NotInit  1bea0890:06daf0b0 <<
7a77385c  40020da      7d0 System.Net.IPAddress  0   shared   static IPv6Loopback
    >> Domain:Value  000d0548:NotInit  1bea0890:06daf110 <<
7a77385c  40020db      7d4 System.Net.IPAddress  0   shared   static IPv6None
    >> Domain:Value  000d0548:NotInit  1bea0890:06daf170 <<

Out I.P address is in the m_Address property whose value is 552882186. As you can see, it is not easy to convert 552882186 into a readable I.P. address. In order to identify the I.P. address represented by this value, we’ll have to examine raw memory. As you can see, the address of the object is 0ae055a8 and m_Address property is at the offset 4. This means, that m_Address is at the memory location 0ae055a8 +4 = 0ae055ac. An I.P. address has four parts, and each part is 1 byte (e.g. 192.168.10.50). Let’s examine the memory location 0ae055ac using the db command (dump bytes). Here is the output:

0:024> db 0ae055ac
0ae055ac  0a 50 f4 20 00 00 00 00-00 00 00 00 00 00 00 00  .P. ............
0ae055bc  00 00 00 00 d0 55 e0 0a-02 00 00 00 00 00 00 00  .....U..........
0ae055cc  00 00 00 00 58 b0 12 79-08 00 00 00 00 00 00 00  ....X..y........
0ae055dc  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0ae055ec  58 2d 12 79 04 00 00 00-2c 90 0f 79 00 00 00 00  X-.y....,..y....
0ae055fc  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0ae0560c  58 2d 12 79 01 00 00 00-5c 38 77 7a a8 55 e0 0a  X-.y....\8wz.U..
0ae0561c  00 00 00 00 58 2d 12 79-00 00 00 00 f0 97 0f 79  ....X-.y.......y

In the above output, 0a 50 f4 20 is out I.P. Address. As this output is HEX, let’s convert this to decimal:

0a = 10

50 = 80

f4 = 244

20 = 32

As you can see, the I.P. address represented by the System.Net.IPAddress object in this case is 10.80.244.32

Hope you find this helpful!

Tehnoon