Friday, July 7, 2017

SharePoint 2013: how to move a wildcard inclusion path site collection to root


This posting consolidates notes and references on how to move a target site collection from its wildcard inclusion path to the root of that path.  This effort is part of a larger effort to migrate a web application from wildcard inclusion topology to an explicit inclusion topology.

The procedure begins by first performing SQL Server backups of all content databases.  Next, a site collection backup is performed using the SharePoint commandlet, Backup-SPSite.  Once the target site collection has been backed up, the next task is to perform a SharePoint detach of all content databases of the target web application.  You may wish to followup this with a SQL Server detach as well, and then archiving of these databases.  Once all of the databases have been removed from the web application, the next step involves creating a new blank content database.


  1. Perform SQL Server backups of target web application content databases.  Use SQL Server Management Studio.
  2. Perform a site collection backup of the target site collection.  Use Backup-SPSite.  Example:
    Backup-SPSite "http://dev/sites/test1/" -Path E:\test1.bak -UseSqlSnapshot
  3. Perform SharePoint detach of target web application content databases. Use Central Administration (CA > Application Management > Databases > Manage content database). Or use Dismount-SPContentDatabase. Example:
    Dismount-SPContentDatabase "WSS_Content_OLD"
  4. Create new content database at target web application. Use Central Administration (CA > Application Management > Databases > Manage content database). Or use New-SPContentDatabase.  Example:
    New-SPContentDatabase -Name  "WSS_Content_NEW" -WebApplication
  5. Execute Restore-SPSite against the site collection backup.  Example:
    Restore-SPSite "http://dev/" -Path E:\test1.bak -Force -DatabaseServer "DEV" -DatabaseName "WSS_Content_NEW"
  6. Execute IISRESET
  7. Remove wildcard inclusion managed paths from web application.  Use Central Administration (CA > Application Management > Web Applications > Manage web applications > [select the target web application] > Manage > Managed Paths.
  8. Update site collection navigation.  For example, if Managed Navigation is being used, will need to update navigation term set and then re-assigned navigation to that term set.
  9. Fix any custom master page JS or CSS references.  CSS reference URLs include the entire path.  These will need to be updated



SharePoint 2013 TIP: Export All Unique Permissions from Site Collection using PowerShell

The best PowerShell script that I have found to date for inventorying a site collection's user and group permissions is one developed by Guru Karnik and published in this TechNet Wiki posting.  It runs against one site collection at a time and conveniently outputs its results to a CSV file.  The site collection URL and path to where to write the output file are entered from the command line.  Output lists the following properties:

  • SiteURL [Url to site collection or subweb]
  • SiteTitle [name of site collection or subweb]
  • ObjectType [site, list, document library]
  • ObjectUrl [relative to site collection URL]
  • ListTitle [NA if site or subweb]
  • MemberName [simple name of user or group]
  • MemberLoginName [claims-based name of user or simple group name]
  • MemberType [SPUser, SPGroup, SPGroupMember]
  • JobTitle [NA if SPUser or SPGroup, or blank if SPGroupMember]
  • Department
  • ParentGroup
  • GroupOwner [NA if type SPUser or not set, otherwise as set]
  • RoleDefinitionBindings [Full Control, Design, Read, Restricted Read, etc, etc]
Though this script was originally developed by Guru for SharePoint 2010, I have found it to successfully execute against SharePoint 2013.


Friday, June 16, 2017

SharePoint 2013: Some or all identity references could not be translated


Experienced the following error after navigating to the Configure service accounts page:
Re-attempted several times to navigate to the page, but without success.  Began troubleshooting.


  1. Performed search on error text, "Some or all identity references could not be translated."
  2. Identified potentially applicable posting, FarmCredentialManagement.aspx, by Nelson Lamprecht.  
  3. Opened elevated SharePoint Management Shell
  4. Executed commandlet, Get-SPManagedAccount | ft -auto, Two farm service accounts were listed: an older one and its replacement.  The older one had been previously removed from Active Directory, but it still appeared in SharePoint.
  5. Executed commandlet, Get-SPManagedAccount -Identity "NSTEST\Stephan.bren.srv" | Remove-SPManagedAccount
  6. Re-executed Get-SPManagedAccount | ft -auto,  No accounts are listed that have null password expiration.
  7. Re-attempted to navigate to the Configure service accounts page, and this time was successful.


  1. List managed accounts.
  2. Identify the account(s) having null PasswordExpiration.
  3. Remove those management accounts having null PasswordExpiration.


Wednesday, June 7, 2017

SharePoint 2013: Simple search customizations


This posting collates notes on implementing simple Search customizations.  This posting is updated as new and simple customizations are identified and documented.

Promoted Custom Search Results

 A new customer requirement involves the following: whenever a user is at a particular web and performs a search (using the standard search query text box), the search results page should first list the results of the query as applied against a particular list in that web, followed by the general search results.  Additionally, this custom search result should appear only when the user searches on a query term that corresponds to a number in a custom column in that list.  The numbers that appear in this list range from 5001 to 11945.  The solution to this requirement involves the implementation of a promoted results block based upon a new query rule and a regular expression to filter the query term. Let's review this requirement as it applies to Search:
  • Requirement
    • Conditionally promote important results from a custom list
  • Method
    • New Query Rule
  • Scope
    • Web
  • Context
    • Local SharePoint Results
  • Conditions
    • Query term is a number
    • Number is within a specific range {5001..11945}
  • Actions
    • Promote conditional results as a block
    • Block appears before other results
    • Filter results based upon query term equaling a number in the custom column
The solution implemented here doesn't require farm administrator involvement, but can be implemented by a site collection administrator or someone having Full Control for the target web.
  1. Navigate to: Settings > Site Settings > Search > Query Rules.
  2. Look for the dropdown that shows "Select a Result Source..."  Open this dropdown, and then select Local SharePoint Results (System).
  3. Click on New Query Rule.
  4. Enter a name for this query rule.  This name is not seen by users but is the name that will be shown on the Query Rules page. 
  5. In the Query Conditions group, from the first dropdown, select Advanced Query Text Match. After you do this, a new set of configuration fields will appear below it.
  6. Select Query matches this regular expression, since a regular expression is needed to filter for the range of numbers.
  7. Now enter the regular expression:
    The range of numbers for which the query rule should filter is 5001 - 11945.  It is convenient to look at this range is comprising two strings: one of 4 digits and a second one of 5 digits. A regular expression developed for each string engages the range of each digit in that string.  Putting these two regex rules together, gives us two regular expressions:

    "[5-9][0-9][0-9][1-9]" and "1[0-1][0-9][0-4][0-5]"

    where individual digit ranges are made known to the regex engine by brackets "[ ]". The first expression filters for the range 5001 - 9999 and the second expression filters for the range 10000 - 11945. Combining these expressions into a single regular expression requires the alternation operator "|", like so:


    This is what must be entered into the regular expression box.
  8. Enable the Entire query matches exactly option.  
  9. In the Actions group, click Add Results Block.  The Add Results Block dialog appears.
  10. Enter a title for the results block.  This title will be displayed for the block when it appears on the results page.
  11. In the Query section, click Launch Query Builder.  The Build Your Query dialog appears.
  12. Delete any text currently in the Query text box.  By default, this will display {subjectTerms}.
  13. From the Property filter dropdown, select the name of the custom column containing the numbers.  If you don't find the property listed, select --Show all managed properties-- and try again.
    Note: the property names that you see displayed here are not necessarily the actual current names of list columns.  These are the managed properties that are currently mapped to that crawled properties configured for the list columns.  If a new column was created at the site collection level, a crawled property is automatically created for it.  If its created locally at the list level, a crawled property must be created for it manually.  If you are uncertain as to what the managed property is for a column, see the Notes section below for guidance on how to find this.
  14. Just below the Property filter dropdown is a smaller dropdown that by default has Contains selected.  Leave this selection as default.
  15. Next to this small dropdown is another dropdown, the Select value dropdown.  From this dropdown, select subjectTerms - the entire query.
  16. Lastly, click the Add property filter button.  The property filter is then added to the Query text box.
  17. Click OK.
  18. Leave the Search this Source dropdown as default.  
  19. Select the number of items you want to have listed in the promoted results block.  For the example discussed here, only one result will be of value and that is the result where the custom list column value is equal to the query term value.
  20. Click Save.  The new query rule goes into affect immediately.


  • SharePoint hierarchy: Farm > Site Collection > Web
  • Discovering the Crawled Property name associated with a column
    1. Navigate to the list. Make sure that you are viewing a list view that features the target column.  The URL should only display the path to the list, without any parameters. 
    2. Perform a sort of the list by that column (hover the cursor over the column title, etc). 
    3. Once the sort completes, look up in the URL address bar again.  There will now be a hash code and other parameters appended to the core view URL.  Look for the SortField parameter, and then note down the value following this parameter (just past the "%3D" and extended to the hyphen "-"). This will be the crawled property name associated with the column you sorted on.  Copy this string.
    4. Now go: Settings > Site Settings > Search > Schema.
    5. Click on the Crawled Properties hyperlink.  
    6. Paste the string from step 3 into the Crawled properties text box, and then click the green arrow box below.  A single result should be displayed.  The first column lists the crawled property you searched for and the second column lists the property it is mapped to.  This mapped property is what is listed in the Property dropdown in the Query Builder dialog and is the property that you use when creating a custom query.
  • tbd

Friday, April 21, 2017

SharePoint 2013: Could not activate SharePoint Server Publishing web feature


Developers need to have the SharePoint Server Publishing Infrastructure (site) feature on the target site collection and the SharePoint Server Publishing (web) feature activated on the target site collection web in order for a custom solution to function successfully.  The custom solution relies upon some of the templates and pages made available by these features.  The administrator verifies that the SharePoint Server Publishing Infrastructure (site) feature is already activated and that the Publishing (web) feature is not activated.  When he tries to activate Publishing using Manage site features, activation fails.  Developers must have the SharePoint Server Publishing (web) feature activated in order to deploy.  This posting consolidates notes associated with analyzing, troubleshooting and resolving this issue.


  • Facts
    • Legacy farm, functional and operational, but having some unknown history and configuration changes.  Original SharePoint administrator long since departed.
    • Numerous customizations: sandbox, farm, deployed via WSPs, or direct modification of master pages and other pages. History of third part and in-house developed solutions added and then not used (e.g., Bamboo, Metalogix) or partially or incompletely removed (e.g., de-activated, but web parts still deployed to pages, de-activated but still installed, etc).
    • Heavily customized target site collection dedicated to delivering specific set of capabilities to small but critical user base.
    • Developers need to have SharePoint Server Publishing Infrastructure (site) feature and the SharePoint Server Publishing (web) feature activated on the target site collection in order for a custom solution to function successfully.
    • SharePoint Server Publishing Infrastructure feature already activated on the site collection and verified in Site Collection Administration > Site collection features.
    • SharePoint Server Publishing feature not activated on the web and could not be activated via Site Actions > Manage site features.
    • Correlation ID presented on activation failure.
    • Initial tentative diagnosis is failure of dependent feature to activate.
  • Troubleshooting Steps
    1. Reviewed ULS log entries: researched for correlation ID in farm server ULS logs.  Eventually found it on one of the WFEs. Reviewed log entries associated with correlation ID.  The listing contains over 200 entries and shows the various tasks associated with activating this feature. There were a number of warnings regarding Metalogix and Bamboo web parts that could be ignored.  There were then a number of entries indicating successful creation of various SharePoint objects, such as columns, lists, document libraries, and so on.  A single failure was found when it began trying to activate 404 error pages from the Publishing feature. Several timeouts (logging gaps) were seen followed by an exception being triggered.
      [timestamp] w3wp.exe (0x4D9C) 0x2B4C SharePoint Foundation General 8grz High The feature '94c94ca6-b32f-4da9-a9e3-1f3d343d7ecb' depends on feature '22a9ef51-737b-4ff2-9346-694633fe4416' which failed to activate...
      This confirmed initial tentative diagnosis.  The what being generally answered, now analysis focused on the why and how to fix.
    2. Performed literature search: performed literature search on feature 22a9ef51-737b-4ff2-9346-694633fe4416. Found that it corresponds with the hidden web-scoped Publishing feature.
      1. SharePoint 2010: Feature GUID and Name Mapping
      2. SharePoint 2013: List of Features "ID, DisplayName, CompatibilityLevel and Scopes"
      3. Failed to activate feature 'Publishing' (ID: 22a9ef51-737b-4ff2-9346-694633fe4416)
      4. Activation Dependencies and Scope
      5. Can't activate Server Publishing
      One posting (5) suggested resolving this by de-activating / re-activating the site-scoped SharePoint Server Publishing Infrastructure feature followed by re-attempting to activate the web-scoped SharePoint Server Publishing feature.
    3. Activate Features: tried de-activating, re-activating publishing infrastructure feature followed by trying to activated publishing feature.  First performed backup of the farm. Then performed activation using UI.  After business hours.  The publishing infrastructure feature feature was de-activated / re-activated without issue.  However, trying to activate the publishing feature again resulted in failure.  Correlation ID provided.
    4. Reviewed ULS logs: performed a review of the ULS logs for the new correlation ID. Logs found on same server as previously.  Reviewed this group of entries - about the same number as previous; also presented almost identical entries.  Failure again occurred at same point.  The fact that publishing infrastructure site feature could be de/re-activated is encouraging and would appear to limit the problem scope of the issue.  Tentative diagnosis is permissions issue: folder containing 404 pages not accessible, writable, etc.
    5. Performed new literature search: performed new literature search for solutions paths. Some postings suggest using PowerShell to activate feature (3) and using the "Force" parameter.  Some internal discussion that feature activation should be performed both for Publishing infrastructure and Publishing, even though Publishing infrastructure already activated.
      1. Enable-SPFeature
      2. Publishing Feature failed to activate
      3. Can't activate 'SharePoint Server Publishing' in 'Site Features'
      4. Unable to Activate Publishing Infrastructure Feature in Site collection of SharePoint 2013
    6. Activate Features: tried de/re-activating Publishing Infrastructure feature followed by activating Publishing feature, both using the Force.  Not clear whether it was necessary to de/re-activate Publishing Infrastructure feature prior to activating Publishing feature. Script that was used:
      $siteUrl = "[URL]"
      $siteCollection = Get-SPSite $siteUrl
      Enable-SPFeature "PublishingSite" -Url $siteCollection.Url -force
      Enable-SPFeature "PublishingWeb" -Url $siteCollection.Url -force
      This time, activation succeeded for Publishing feature.  


  • Activate Publishing web feature via Enable-SPFeature using Force parameter.



  • Microsoft SharePoint Hierarchy: Farm > Web Application > Content Database > Site Collection > Web

Wednesday, April 19, 2017

SharePoint 2013 TIP: How to get managed account passwords via PowerShell

To get the password for each and every  managed account in the farm, just run this PowerShell script in an elevated SharePoint Management Shell:
function Bindings() { return [System.Reflection.BindingFlags]::CreateInstance -bor [System.Reflection.BindingFlags]::GetField -bor [System.Reflection.BindingFlags]::Instance -bor [System.Reflection.BindingFlags]::NonPublic } function GetFieldValue([object]$o, [string]$fieldName) { $bindings = Bindings return $o.GetType().GetField($fieldName, $bindings).GetValue($o); } function ConvertTo-UnsecureString([System.Security.SecureString]$string) { $intptr = [System.IntPtr]::Zero $unmanagedString = [System.Runtime.InteropServices.Marshal]::SecureStringToGlobalAllocUnicode($string) $unsecureString = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($unmanagedString) [System.Runtime.InteropServices.Marshal]::ZeroFreeGlobalAllocUnicode($unmanagedString) return $unsecureString } Get-SPManagedAccount | select UserName, @{Name=”Password”; Expression={ConvertTo-UnsecureString (GetFieldValue $_ “m_Password”).SecureStringValue}}

You can also obtain the password of any web application pool by running this in an elevated command shell:
C:\Windows\System32\inetsrv\appcmd list apppool "[App Pool Name]" /text:*


Monday, April 17, 2017

SharePoint 2013 TIP: Resources for Finding Feature IDs

The following are methods for discovering feature IDs:

Friday, March 10, 2017

SharePoint 2013 TIP: How to create and remove a Managed Metadata Service Application


This posting is a stub that collates ongoing notes on creating, updating and removing a Managed Metadata service application.  Removing the managed metadata service application also includes removing the managed metadata database and application pool (if one was created specifically for this service).

Creating the service using PowerShell

New-SPServiceApplicationPool -Name AppServicesAppPool -Account "DOMAIN\spFarm" New-SPMetadataServiceApplication -Name "Managed Metadata Service Application" -ApplicationPool "AppServicesAppPool" -DatabaseName "ManagedMetadata" New-SPMetadataServiceApplicationProxy -Name "Managed Metadata Service Application Proxy" -ServiceApplication "Managed Metadata Service Application"


  • Whenever possible, I prefer using PowerShell to administer SharePoint - particularly when creating service applications.  

SharePoint 2013: create Search service for single-server dev farm


This procedure deploys a Search Service Application to a single-server SharePoint Server 2013 Enterprise farm primarily used by a SharePoint developer who also needs Search capability. The server has just one drive, the system drive.   It also leaves the crawl default, or the Search service account, but you can always change this later through Central Administration.


To get started, you first need to collate the values for some standard parameters:
Parameter ValueComment
$svr devserver name
$SvcAcct DOMAIN\spSearchSearch service identity
$SSAName Search ServiceSearch service name
$DBPrefix Search_search service database name prefix
$IndexLocation C:\SSAIndexpath to the location of the index
Once you have these constants defined, open an elevated SharePoint Shell and execute the following script:
$Svr = "dev" $SvcAcct = DOMAIN\spSearch $AdminAcct = Get-SPManagedAccount -Identity $SvcAcct $QueryAcct = $AdminAcct $SSAName = "Search Service" $DBPrefix = "Search_" $IndexLocation = "C:\SSAIndex" $SSISvr = get-SPServiceInstance -server $Svr |?{$_.TypeName -eq "SharePoint Server Search"} $err = $null Start-SPEnterpriseSearchServiceInstance -Identity $SSISvr $AdminAppPool = new-SPServiceApplicationPool -name $SSAName"_AppPool" -account $AdminAcct  $QueryAppPool = $AdminAppPool $SearchApp = New-SPEnterpriseSearchServiceApplication -Name $SSAName -applicationpool $AdminAppPool -databasename $DBPrefix"_AdminDB" $SSAProxy = new-spenterprisesearchserviceapplicationproxy -name $SSAName" ApplicationProxy" -SearchApplication $SearchApp $SearchTopology = $SearchApp.ActiveTopology.Clone() New-SPEnterpriseSearchAdminComponent -SearchServiceInstance $SSISvr -SearchTopology $SearchTopology New-SPEnterpriseSearchContentProcessingComponent -SearchServiceInstance $SSISvr -SearchTopology $SearchTopology New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchServiceInstance $SSISvr -SearchTopology $SearchTopology New-SPEnterpriseSearchCrawlComponent -SearchServiceInstance $SSISvr -SearchTopology $SearchTopology New-SPEnterpriseSearchIndexComponent -SearchServiceInstance $SSISvr -SearchTopology $SearchTopology -RootDirectory $IndexLocation New-SPEnterpriseSearchQueryProcessingComponent -SearchServiceInstance $SSISvr -SearchTopology $SearchTopology $SearchTopology.Activate()

That's it. You're done. Now you can fire up Central Administration, navigate to Farm Search Administration and see everything.



  • If you need to remove the Search service application, be sure to review the reference on completely removing it as it provides helpful steps to ensure you get all of it off the server before trying to re-install it again.

Wednesday, March 8, 2017

SharePoint 2013 TIP: How to implement multi-level flyouts in global navigation

The default depth for multi-level flyouts in global navigation is 2; in other words, you can configure a single dropdown list of menu options for each menu and on flyout for each of those menu options:
The depth of the flyouts that you can have is set by the MaximumDynamicDisplayLevels property of the SharePoint AspMenu control, which you'll find in the master page.  This property is set to "2" by default.  To be able to have a flyout on one of these flyouts, you need to increase this property from "2" to "3"; and that enables you to create global navigation menus like so:


  • The tag will look something like this:
    <SharePoint:AspMenu ID="TopNavigationMenu" Runat="server" EnableViewState="false" DataSourceID="topSiteMap" AccessKey="&lt;%$Resources:wss,navigation_accesskey%&gt;" UseSimpleRendering="true" UseSeparateCss="false" Orientation="Horizontal" StaticDisplayLevels="2" AdjustForShowStartingNode="true" MaximumDynamicDisplayLevels="2" SkipLinkText="" />
  • The above TIP presumes the use of Managed navigation.  See reference 4 for details.

SharePoint 2013 TIP: How to quickly deploy a State service application

The State service is one of the easiest to instantiate and requires just a few lines of PowerShell - you can even do it in one line if you want. This service application stores temporary data in the State database for use by other service applications and components, such as the Chart web part, some Search service crawl reports, and others.
$sa = New-SPStateServiceApplication -Name "State Service Application" New-SPStateServiceDatabase -Name "State" -ServiceApplication $sa New-SPStateServiceApplicationProxy -Name "State Service Application Proxy" -ServiceApplication $sa -DefaultProxyGroup
Executing these commandlets obtains the results shown in the figure below



  • "The chart cannot be rendered.  This may be due to a misconfiguration of the Microsoft SharePoint Server State Service." You'll see this error if you try to view the Search Service Crawl Rate crawl report and don't have a State service deployed yet to your farm. Just create a new State service application and this problem goes away immediately.
  • tbd

Wednesday, January 11, 2017

SharePoint 2013: the Service Application being requested does not have a Connection associated with the Central Administration web application.


You create a new Managed Metadata service application (MMSA).  You then navigate to the Term Store Management Tool and see the following error message:
The underlying issue here is associated with the second error message.  Resolving it involves:
  1. Granting the Managed Metadata Service Application application pool identity access permission to the service application and
  2. Associating the Managed Metadata Service Application proxy with the web application.


  1. Grant the MMSA application pool service account access to the MMSA
    1. Navigate to: Central Administration > Application Management > Service Applications > Manage service applications.
    2. Click on the white space to the right of the Managed Metadata Service Application link (don't click on the link itself).  This selects that service application.
    3. On the SERVICE APPLICATIONS tab of the ribbon, in the Sharing group, click on the Properties button.
    4. Scroll down to the Application Pool group, and then take note of the name of the application pool that is shown under Use existing application pool.  Now you need to find the service account identity of this application pool.
    5. Click Cancel.
    6. Launch an elevated SharePoint Management Shell.
    7. Execute: Get-SPServiceApplicationPool.  This returns a list of all SharePoint-related application pools and their identities.
    8. Find the target application pool, and then note down its ProcessAccountName.  This is the service account that is the identity of the application pool.
    9. Now, on the SERVICE APPLICATIONS tab of the ribbon, in the Sharing group, click on the Permissions button.
    10. Verify that the application pool service account you identified in the previous step has been granted at least Read Access to Term Store access.  If you don't see the service account listed here, grant the service account the level permission access appropriate to your web application, and then click OK.
  2. Associate the MMSA proxy with the target web application
    1. Navigate to: Central Administration > Application Management > Service Applications > Configure service application associations.
    2. From the View dropdown, to the right, select Web Applications.
    3. Click on the Application Proxy Group associated with the target content web application.  For default proxy groups, this will be default.  The Configure Service Application Associations dialog appears.
    4. You may see more than one item here.  There'll be a proxy listed here for each service application you have created.  For this test instance, only the Managed Metadata Service Application has been created and so only one proxy is listed.
    5. Enter a check for the Managed Metadata Service Application Proxy, and then click OK.
    6. Back on the Service Application Associations page, you'll now see a Managed Metadata Service Application proxy associated with the target web application.  If you have other service applications associated with the target web application, they will also be listed here.  
    7. The configuration you made here is immediately implemented, and the Term Store Management Tool is now accessible.


  • You can recreate this issue by simply unchecking the proxy association.

Google Chrome TIP: stop Chrome from always prompting for authentication for local intranet

If your Google Chrome instance is constantly prompting you to logon, when merely trying to connect to local intranet sites, there's a simple fix: add the site to the Local Intranet zone.  This procedure accurate for version 55.0 m (64-bit).
  1. Launch Google Chrome.  Logon as you would normally if prompted.
  2. In the top right corner, look for a series of three dots, vertically aligned.  If you hover the cursor over it, a popup will state Customize and control Google Chrome.
  3. Click on this icon.  A dropdown menu appears.
  4. Scroll down this menu to the Settings option and select it.
  5. The Google Chrome Settings page is displayed.
  6. Alternatively, enter Chrome://settings into the Google Chrome address bar.
  7. Scroll down this page to the bottom, and then click on the link, Show advanced settings.
  8. Scroll down the page to the Network group.
  9. Click the button, Change proxy settings... .
  10. The usual Internet Properties dialog appears. Select the Security tab.
  11. On the Security tab, select the Local Intranet zone, and then click the Sites button.
  12. The Local intranet dialog appears.
  13. Click on the Advanced button.
  14. Enter the URL to the intranet site, starting with http:,and then click the Add button.
  15. If a new prompt appears, stating The site you specified already exists in the Trusted sites zone..., click Yes.
  16. Click Close, and then OK.
  17. Exit Google Chrome.