Managed Path sharepoint

Let me document the Frequently Asked Questions on SharePoint Managed Paths during my training sessions:

What is Managed Path in SharePoint?

A managed path is a location within a web application in which you can have site collections. When you create a web application, there are two managed paths created with it. The first managed path is called the Root “/” path of explicit inclusion type. The second is called “sites” with wildcard inclusion path. SharePoint 2010 My Site host comes with “Personal” Wildcard managed path.

Why We need Managed Paths in SharePoint?
Managed Paths in SharePoint used to group multiple sites based on some criteria. Also helps to maintain a logical structure in SharePoint. Say, You want to group all Sales department sites, then you can have: http://company/sales/Site1/ , http://company/sales/Site2/, etc.

SharePoint managed path examples:

Lets take an example. A typical SharePoint URL could be: “http://company.com/sites/Sales/apac/”
Where

  • http://company.com – Web Application
  • Sites–  Managed path
  • Sales – Site collection
  • apac – Sub-site

Explicit vs Wildcard
There are two Types of Managed Paths we can create:

  1. Explicit inclusion : Path can be explicitly used for only one site collection. (E.g. http://company/sites/hr) and no site collections can be created underneath the path. (But sub-sites can be created under site collection)
  2. Wildcard inclusion: If you want to create site collections underneath a specific path, choose “Wildcard” (for example, “Sites” in http://server/sites/). Unlimited site collections can be created under the given path.
managedpath

managedpath

How to Configure Managed Paths for SharePoint 2010 Web Applications?

Managed Paths are defined at web application level. You can have different paths for different web applications. They cannot be defined for host header site collections. To define managed path in SharePoint 2010, Go to:

  1. Central Administration >> Application Management.
  2. In Application Management page, click on Manage Web Applications
  3. Click the Web application for which you want to configure Manage Paths
  4. Now from the ribbon, click Managed Paths.
  5. From here you can configure Managed Paths for a particular web application.
  6. Once you are done with managed paths, click OK.
managed path

managed path

Nested Managed paths

is it possible to nest a managed path under another managed path? Yes! You can create nested managed paths! Say for E.g. You create a Managed Path “/sites/” , then You create managed path as “/sites/sales”. Now you can create site collections under each of these paths.

But you cannot create a site collection under /sites/  as “Sales”, because once you create the managed path “Sales” under “Sites” it is marked as reserved!

SharePoint Managed Path Limits

Its a best practice to have SharePoint managed paths < 20. As per SharePoint 2010 Software boundaries and limit  20 Managed Paths can be created per Web application.You can expect performance issues if you exceed this limit!

Can I Create Site collections Under Root?

By default, Root Managed Path (/) is created as Explicit inclusion, which means you can create only one site collection at the root of the web application. However you can delete and Re-create it with Wildcard inclusion to enable site collections under Root.

How to Change site collection managed path
If you want to change the managed path of your site collection, You have to:

  • Backup your site collection
  • Delete your site collection
  • Restore your site collection with new managed path
Refer my post: How to Change Site Collection URL for step by step instructions.

What if I delete the Managed path in use?
Answer: Your SharePoint Sites under the specific managed path will result: HTTP 404 Page Not Found!

SharePoint Managed path not in list?

Managed Path Not available in Create Site Collection Page, After deleting the site collection which was occupying the specified managed path already ? Refer my article for the solution: Managed Path Not available

How to Create/Delete SharePoint Managed path Programmatically with C# object model or Powershell? 

To Manage SharePoint managed paths in C# object model and in PowerShell, Refer my article: Programmatically Get/Create/Delete Managed Paths in SharePoint

Advertisements

Repairing distributed cache with PowerShell

  • Recently we had issues with our distributed cache system that was set up on are farm quite some time ago when I built it with SPAuto-Installer.  This could have been from rolling out cumulative updates or what have you.  There is very little documentation on the web for this.

*  In our case we had 4 servers (2 web front-ends and 2 application servers)  all with the distributed cache enabled.  Only one server was running the distributed cache.

*  The correct topology for distributed cache is for it to exist on the web front-ends.  So we made some changes to the farm.

Clean up all 4 Servers using the following commands:

#Stopping the service on local host

Stop-SPDistributedCacheServiceInstance -Graceful

#Removing the service from SharePoint on local host.

Remove-SPDistributedCacheServiceInstance

#Cleanup left over pieces from SharePoint

$instanceName =”SPDistributedCacheService Name=AppFabricCachingService”

$serviceInstance = Get-SPServiceInstance | ? {($.service.tostring()) -eq $instanceName -and ($.server.name) -eq $env:computername}

$serviceInstance.delete()

Then we added the cache host back to WEB01:

#Re-add the server back to the cluster

Add-SPDistributedCacheServiceInstance

We then checked the SPDistributedCacheClientSettings and found that “MaxConnectionsToServer” was set to 16 for all containers.

$DLTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

$DLTC

We used the following script to change  “MaxConnectionsToServer” back to 1 and increase the timeout for each container.

Add-PSSnapin Microsoft.Sharepoint.Powershell

#DistributedLogonTokenCache

$DLTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache

$DLTC.MaxConnectionsToServer = 1

$DLTC.requestTimeout = “3000”

$DLTC.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache -DistributedCacheClientSettings $DLTC

#DistributedViewStateCache

$DVSC = Get-SPDistributedCacheClientSetting -ContainerType DistributedViewStateCache

$DVSC.MaxConnectionsToServer = 1

$DVSC.requestTimeout = “3000”

$DLTC.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedViewStateCache $DVSC

#DistributedAccessCache

$DAC = Get-SPDistributedCacheClientSetting -ContainerType DistributedAccessCache

$DAC.MaxConnectionsToServer = 1

$DAC.requestTimeout = “3000”

$DAC.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedAccessCache $DAC

#DistributedAccessCache

$DAF = Get-SPDistributedCacheClientSetting -ContainerType DistributedAccessCache

$DAF.MaxConnectionsToServer = 1

$DAF.requestTimeout = “3000”

$DAF.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedCache $DAF

#DistributedActivityFeedLMTCache

$DAFC = Get-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedLMTCache

$DAFC.MaxConnectionsToServer = 1

$DAFC.requestTimeout = “3000”

$DAFC.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedLMTCache $DAFC

#DistributedBouncerCache

$DBC = Get-SPDistributedCacheClientSetting -ContainerType DistributedBouncerCache

$DBC.MaxConnectionsToServer = 1

$DBC.requestTimeout = “3000”

$DBC.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedBouncerCache $DBC

#DistributedDefaultCache

$DDC = Get-SPDistributedCacheClientSetting -ContainerType DistributedDefaultCache

$DDC.MaxConnectionsToServer = 1

$DDC.requestTimeout = “3000”

$DDC.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedDefaultCache $DDC

#DistributedSearchCache

$DSC = Get-SPDistributedCacheClientSetting -ContainerType DistributedSearchCache

$DSC.MaxConnectionsToServer = 1

$DSC.requestTimeout = “3000”

$DSC.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedSearchCache $DSC

#DistributedSecurityTrimmingCache

$DTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedSecurityTrimmingCache

$DTC.MaxConnectionsToServer = 1

$DTC.requestTimeout = “3000”

$DTC.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedSecurityTrimmingCache $DTC

#DistributedServerToAppServerAccessTokenCache

$DSTAC = Get-SPDistributedCacheClientSetting -ContainerType DistributedServerToAppServerAccessTokenCache

$DSTAC.MaxConnectionsToServer = 1

$DSTAC.requestTimeout = “3000”

$DSTAC.channelOpenTimeOut = “3000”

Set-SPDistributedCacheClientSetting -ContainerType DistributedServerToAppServerAccessTokenCache $DSTAC

  • We then stopped and restarted Distributed Cache from Central Admin on WEB01
  • We then attempted to start “Distributed Cache” on WEB02 and received error “failed to connect to hosts in the cluster”
  • Performing a TRACERT from WEB01 to WEB02, we can see a device is in the middle (10.21.1.5).
  • Installed Telnet

Import-Module servermanager

Add-WindowsFeature telnet-client

  • Telnet from WEB01 to WEB02 on port 22233 and the connection was established.
  • We then stopped, cleaned and added WEB02 back to the cache farm
  • #Stopping the service on local host

    Stop-SPDistributedCacheServiceInstance -Graceful

    #Removing the service from SharePoint on local host.

    Remove-SPDistributedCacheServiceInstance

    #Cleanup left over pieces from SharePoint

    $instanceName =”SPDistributedCacheService Name=AppFabricCachingService”

    $serviceInstance = Get-SPServiceInstance | ? {($.service.tostring()) -eq $instanceName -and ($.server.name) -eq $env:computername}

    $serviceInstance.delete()

    Then we added the cache host back to WEB02:

    #Re-add the server back to the cluster

    Add-SPDistributedCacheServiceInstance

    This time it started!

    • Now we have WEB01 and WEB02 servicing distributed Cache
  • We checked the ULS Logs with ULSViewer and found all successful events for Distributed Cache.
  • Status

    =======

    Distributed cache is now healthy and in a working state on both WFE Servers.

    Performance Test SharePoint

    Why Performance Testing ?

    If you work on a team responsible for the delivery of SharePoint into your organization there’s usually a mountain of tasks to complete before making it live. One of the most vital tasks is to make sure that SharePoint is “fast” enough to meet the requirements of your users. If you get performance problems after going live this can easily ruin all of your hard work and – even worse – your users will think SharePoint sucks!

    So, by the time you “go live” you should be confident of the following :

    • You know the maximum load your service can take.
    • You know your service can run for a pro-longed period of time.
    • You know the point at which you may need to add more servers, so you can plan.
    • When you do get to maximum load you need to know where the bottle necks in your service are, (e.g. SQL, Network, SP servers).

    If you don’t know these metrics up front, then you are going to have to react as problems occur. If you have to react it will be probably be done under extreme pressure, usually because your boss is yelling at you!

    So how do you find out these performance metrics ?

    One of the best ways to discover how well your environment can cope is to carry out some performance tests using a tool that will emulate the load and expected journeys of your user base.

    User Journeys

    Not every user will use SharePoint in the same way. You will have some users that download a document, some that will publish documents, some that will use Search, or even some that will use be 100% socialites. In the testing world these usage patterns can be mapped onto something called a User Journey. To get started with Performance Testing, you will need to know what these journeys are likely to be and also what the mix will be. You can either take an educated guess (“guestimate”) on what these journeys will be or even better, run a pilot on a good cross-section of staff before going live. You can then use the actual usage data from the pilot phase and feed that into a typical user journey. Both SharePoint analytics and the IIS logs will give you all the data you need.

    Once you have this data you can then list all of the types of journeys,

    e.g. :

    “Casual Browser”

    • Log-in
    • Hit the home page
    • Do a search
    • Read a document

    Another journey may be :

    “The Social User”

    • Log-in
    • Hit the home page
    • Go to their MySite (some pre-provisioned, some not)
    • Add a status update
    • Add a forum post
    • Like a document

    Visual Studio Performance Testing

    If you have Visual Studio Ultimate, you can take advantage of the testing tools that ship with it. There are a few others such as Load Runner, but they can be pricey. If you take time to learn Visual Studio test tools you will soon be able to perform adequate tests. The other great side effect is that you also are functionally testing your application. So once you automate your testing, you can use it to repeatedly test your app.

    Once really cool thing about Visual Studio Testing is that it’s really easy to record a user journey by simply using the browser to use SharePoint. Once you have completed the journey it will be saved as a web test so that it can automatically be reused under load in your Performance Tests.

    To read more about Visual Studio Testing tools go here.

    Visual Studio Test Agents

    For large implementations, it’s impossible to emulate anything more than 50 users from 1 machine (aka Test Agent). You will be constrained by the machines CPU, Memory or Network I/O. To increase the load you need to install the Visual Studio Test Agent service on more than 1 machine. As an example, to emulate 600 concurrent users I used 10 machines to spread the load.(It’s quite easy to see when a machine is constrained as VS collects performance data from the agent and things go RED.)

    Once configured, each Test Agent, will emulate several users using SharePoint. Once the Agent has the performance data they will log it to a common SQL Server where it can be analysed.

    Note! You don’t need to buy specific machines for this, you should consider using your existing developer machines. It’s VERY likely you will be doing this kind of testing out of hours, so it’s silly not to use them.

    What performance data to you need to gather ?

    To understand what to look for does require a good understanding of machine architecture and performance counters. However, Visual Studio really helps as it has a pre-recorded set of “important” counters. Each counter has a pre-defined threshold, so it will be obvious if there is a problem. For example, if your SQL Server CPU hits 95% this be will clear to see.

    The main things to you want to record for each type of test are :

    • Test Duration
    • WFE’s in Load
    • Agents used
    • Avg. User Load
    • Pages / Sec
    • Avg. Page Time (Sec)
    • Requests / Sec
    • Requests Cached %
    • Avg. Response Time

    Please note, you should gather performance data from all servers involved in providing your SharePoint service. This includes application servers, WFE’s, SQL Servers and also non SharePoint servers. There could be a bottleneck in any one of these that can cause knock on effects and resulting slow performance. 

    Always test customised code.

    Microsoft have already tested standard SharePoint functionality. If there were performance issues they would already be well known and probably fixed. However, Microsoft cannot test any customizations (i.e. code) you have done. Make sure anywhere you have new code (e.g web parts, event receivers, custom pages ect), you include it under load. Custom code is the most likely cause of performance issues as it’s unlikely your developers will have tested it at the loads it will be used at.

    Having said that, you still want to test standard SharePoint as you may have under powered kit. I am just saying pay special attention to custom code.

    Vary the users, browsers and network mix.

    Visual Studio allows you to log-in as different types of users. Do this. Different types of users can cause different paths of code to fire. You may have personalisation features, or different security models that come into play based on user.

    You can also emulate different browsers and networks. Try and match your organization closely.

    What type of tests do you need to perform ?

    The type of tests you can carry out will generally fall into one of these types :

    Goal based Test

    The intention of the Goal-based test is to identify the number of page / requests that can be served while the WFE’s are running at around 70% utilisation. The test runs for 10 minutes and readjusts load based on CPU utilisation.

    Soak Test

    The intention of this test is to hit the production farm at about 50 – 75% of expected peak Usage over long periods of time. This will hopefully identify specific problems that are time related, such as memory leaks, or scheduled tasks that disrupt service.

    Stepped Tests

    The purpose of this test is to gradually ramp up the User load to find the point at which response rates start to fall away.

    Constant Load Tests

    This type of testing hits the servers with a constant load that is expected at peak performance.

    What are the performance steps ?

    In summary, here’s the high-level steps that you need to go through :

    1. Identify your user journeys.
    2. Records your user Journeys using Record and Play with a browser and Visual Studio.
    3. Create Test Scenarios in Visual Studio – (Vary the users, time, browsers, networks, journeys).
    4. Configure “Test Agents” to increase the amount of load.
    5. Run the Tests.
    6. Analyse the results.
    7. Publish findings and make recommendations.

    The Sample Report 

    This sample performance testing report is a 25 page report taken from an actual SharePoint 2010 farm serving 15,000 users. The Farm has 2 App Servers and 4 WFE’s. If you need to do Performance Testing in your organization, you may wish to use it as a reference point.

    Site not appear in IIS Manager,error opening in SharePoint Designer

    I have created a site collection and then create two team sites on sharepoint server. Sites are working fine from central Admin but they are not appearing in IIS manager. Also when I try to edit a sharepoint site on SharePoint designer 2010 follwing error comes.

    Unable to open website following causes:

    1) the web server may not have sharepoint installed

    2)The web server may be temporarily out of service

    3)if you are connecting through a proxy server the proxy settings may be incorrect

    4) An error may be occurred in the web server

    The IIS manager only showing the follwing sites SharePoint 80 and SharePoint central admin

    When I try to create a site on SharePoint designer following error comes:

    The web site must be created on a server that is running Microsoft SharePoint foundation server please choose another location.

    I have installed SharePoint server 2010, SharePoint foundation server 2010 and SharePoint designer on my pc.

    Solution :

    • In IIS Manager, you’re only going to see the Web apps, the site collections and sites are wont show up (if you have another web app that isn’t showing up, that’s a bigger issue. I’d delete it and try to recreate it).

    • The SharePoint Designer issue, I’ve had before. For me, the issue was a firewall setting. But basically if you can get to the pages with the browser, make sure you have correct permissions set for your login, etc.