Microsoft cloud engineer - SharePoint, Office 365, Azure, DotNet, Angular, JavaScript.
Microsoft cloud engineer - SharePoint, Office 365, Azure, DotNet, Angular, JavaScript.

SharePoint 2013

FIXED – AzurePlugin was not able to get Tenant Info from configuration server (CSSA)

While enabling the CSSA (Cloud Search Service Application) I came across this error during first full crawl after successfully completing the on-boarding steps outlined at https://blogs.msdn.microsoft.com/spses/2015/09/15/cloud-hybrid-search-service-application/ with PowerShell scripts.    The Azure plugin was unable to crawl on-premise content.   Root cause was proxy server configuration, which needs to be consistent across three places.  Hope this helps!

 

Central Admin

An unexpected error occurred in the Azure plugin. This item will be retried in the next incremental crawl. ( AzureException AzurePlugin was not able to get Tenant Info from configuration server; SearchID = B056F137-1C77-4792-B402-256B615DBE82 )

 

Verbose ULS

Get-SPLogLevel |? {$_.Area -like "SharePoint Server Search"} | Set-SPLogLevel -TraceSeverity VerboseEx
New-SPLogFile

ULS Log

By running PowerShell commands “Set-SPLogLevel” and “New-SPLogFile” I was able to get verbose URL for the CSSA crawl process.   Here are the entries showing inability to communicate over the proxy server to the Internet.

12/08/2016 15:36:31.55  mssearch.exe (0x195C) 0x0B18  SharePoint Server Search             Crawler:Azure Plugin                amn0f   High       AzureServiceProxy::GetCerts caught AggregateException: The ServicePointManager does not support proxies with the myproxy scheme.  

12/08/2016 15:36:31.55  mssearch.exe (0x195C) 0x0B18  SharePoint Server Search             Crawler:Azure Plugin                amn0g  High       AzureServiceProxy::GetCerts: Failed to get encryption certificates from cert server https://tenant.sharepoint.com for realm 67d7b889-884d-4c2a-a8d8-3ff81f37b497, documents will be send unencrypted (if unecrypted submit is allowed) 

12/08/2016 15:36:31.55  mssearch.exe (0x195C) 0x0B18  SharePoint Server Search             Crawler:Azure Plugin                amn0h  High       AzureServiceProxy::GetAzureTenantInfo caught AggregateException: The ServicePointManager does not support proxies with the myproxy scheme., unable to get EndpointAddress, submit is blocked               

12/08/2016 15:36:31.55  mssearch.exe (0x195C) 0x0B18  SharePoint Server Search             Crawler:Azure Plugin                amn0i    High       AzureServiceProxy caught Exception: *** Microsoft.Office.Server.Search.AzureSearchService.AzureException: AzurePlugin was not able to get Tenant Info from configuration server     at Microsoft.Office.Server.Search.AzureSearchService.AzureServiceProxy.GetAzureTenantInfo(String portalURL, String realm, String& returnPropertyValue, String propertyName)     at Microsoft.Office.Server.Search.AzureSearchService.AzureServiceProxy.SubmitDocuments(String azureServiceLocation, String authRealm, String SPOServiceTenantID, String SearchContentService_ContentFarmId, String portalURL, String testId, String encryptionCert, Boolean allowUnencryptedSubmit, sSubmitDocument[] documents, sDocumentResult[]& results, sAzureRequestInfo& RequestInfo) ***   

 

Resolution

Proxy server settings need to be confirmed in three places.   The crawler was attempting to use “myproxy:8080” DNS names when it actually needs URL format “http://myproxy:8080”   

 

1)  Internet Explorer

Tools > Options > Connections > LAN Settings

Provide either PAC URL (proxy auto config) or proxy server DNS name.

2016-12-12_8-46-00

 

2)  Command Line

NETSH WINHTTP SHOW PROXY

NETSH WINHTTP SET PROXY PROXY-SERVER=”myproxy:8080” BYPASS-LIST=”*.company.com;<local>”

image

 

3)  Dot Net Global [machine.config]

Run notepad

Open “C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config”

Add following XML code

<system.net>
<defaultProxy>
<proxy usesystemdefault=”false” proxyaddress=”http://myproxy:8080” bypassonlocal=”true” />
</defaultProxy>
</system.net>

 

image

 

Notes

  • Completed the “Hybrid Onedrive” click once application to create “ACS” and “SPO” service application proxies before Hybrid Search CSSA onboarding.   https://configure.office.com/

References

2728.image_0ACB058C

I Wanna Patch FAST

Want to patch your SharePoint farms faster?  Try running https://github.com/spjeff/sppatchify

 

The latest version (0.42) includes new PowerShell code for parallel execution of “Upgrade-SPContentDatabase.”  This was implemented with “Get-Job” and PowerShell job management to remote sessions. 

The more user content databases you have, the greater the time savings.  Below are summary statistics from patching a 9 server SharePoint 2013 farm with 200 SQL content databases in just 4 hours.  Each of the 9 servers will spawn 4 PowerShell remoting runspaces for “Upgrade-SPContentDatabase.”  With 36 concurrent worker threads, the queue of 200 content databases now becomes only 6 deep.  

Instead of waiting 200 units of time to process content databases serially, we now only wait 6 units of time for the upgrade database phase.

Larger farms with more user content (and databases) will see significant overall time savings considering how a majority of the traditional patching timeline is processing all content databases.    The binary EXE phase runs with all content databases  removed (Dismount-SPContentDatabase ) so PSCONFIG can complete sooner.    After that is done, content is introduced again (Mount-SPContentDatabase) and upgraded (Upgrade-SPContentDatabase).

 

Amazing speed!!!    Cheers 

 

 

Charts

 

image

 

image

 

image

 

Image result for i wanna go fast

 

 

SPPatchify

Open source hosted on GitHub

 

image

SPPatchify – CU patch entire farm from one script

Patching can be tedious and time consuming.   Why not automate that?  Who wants to be awake all night clicking “Next” and watching SP config wizard?  So  I coded a single PowerShell script to manage the full end-to-end patching process.

 

The script will …

  • Enable PowerShell client remoting.  Connects to farm peer machines.
  • Autodetect current user password from IIS pools
  • Download Microsoft Cumulative Update (CU) media (EXE +CAB) and copy to all servers.   Optionally, you can download to the \media\ sub folder manually.
  • Stop Distributed Cache (DC)
  • Stop SharePoint services
  • Run EXE binary in paralle
  • Wait for EXE to complete and reboot
  • Dismount-SPContentDatabase
  • Start SharePoint services
  • Run SharePoint Config Wizard serially
  • Mount-SPContentDatabase
  • Remove Microsoft Cumulative Update (CU) media from peer servers
  • Ensure IIS started
  • Launch Central Admin with IE
  • Reboot current PC

 

Duration from start to end is incredibly fast.    I tested a 4 server SharePoint 2013 farm and ran the entire process in just 45 minutes.   Stopping services and dismounting content databases speeds up patching significantly.    Automating serial (one-at-time) Configuration Wizard ensures minimal “think time” between steps.   Removing manual human process gives higher consistency while mitigating risk of error.

The script uses Get-SPServer to auto detect farm members.   That enables CU media copy sideways to peers and the stop/start of SharePoint services.   Get-SPContentDatabase is exported to a local CSV file to “snapshot” before patching and later Mount-SPContentDatabase step to present databases again.   The big goal isn’t zero downtime, but rather minimal downtime.  

The entire farm patching process can be managed from one PowerShell window.  Enjoy! 

shades_smile

 

Please leave a comment if you found this helpful.

 

Get Started

  1. https://github.com/spjeff/sppatchify
  2. Extract to “C:\SPPatchify” on any server in the farm
  3. RDP with farm account and run “C:\SPPatchify\SPPatchify.ps1”

 

Flow Diagram

6

 

Screenshots

image
5
image
image
image
image

References

How to detect if MS16-004 hotfix is installed

While managing a number of farms I needed to search and find out if the hotfix for MS16-004 bug was installed.   Stefan posted a helpful solution for the Jan 2016 CU ListView issue at https://blogs.technet.microsoft.com/stefan_gossner/2016/01/15/solution-for-the-list-view-issue-with-ms16-004-january-2016-pu-for-sharepoint-2013/ and some farms have “wssloc2013-kb3114508-fullfile-x64-glb.exe” installed but not all.

 

This PowerShell can be run local or remote to indicate if a given farm has the hotfix.  Below is a remote sample across 40 servers with https://github.com/spjeff/splaunch.  Enjoy! 

shades_smile

 

Code

$p1=$false;
$p=Get-SPProduct;
$p.PatchableUnitDisplayNames |% {
	$n=$_;
	if (($p.GetPatchableUnitInfoByDisplayName($n).patches |? {$_.patchname -like '*3114508*'}).count -gt 0) {
		$p1=$true;
	}
};
$obj = New-Object -TypeName PSObject -Prop (@{'wssloc2013-kb3114508-fullfile-x64-glb'=$p1;});
$obj;

 

Screenshot

image

© Copyright 2016
@ SPJeff

Return to Top ▲Return to Top ▲