Tag Info

Hot answers tagged

30

Just go simple with powershell. Here is how to rename without doing more than that: $a=Get-SPWebApplication | where {$_.Name -match "Old web application name"} $a.Name $a.Name="New web application name" $a.Update() Get-SPWebApplication | where {$_.Name -match "New web application name"} That's all !


14

This should help - "SharePoint Terminology – Farms, Web Front Ends, Web Application and Sites" Specifically - "what is difference between Web and WebApplication?" Generally when you see "Web" mentioned in programming terms (SPWeb) it actually means a means what a user calls a site and a "Site" (SPSite) is a site collection. A Web Application is a unit ...


7

Rather than trying to modify IIS directly, I think it is better to do this in SharePoint Central Administration if you can, particularly if you have more than one web front-end server. To change the URL of your SharePoint try this: Go to Central Administration/Manage Web Applications and select the Web Application. Click on the drop-down on the Delete ...


6

1) Because the Microsoft SharePoint Foundation Web Application service is running on your App Layer. Go to Central Admin -> Manage services on server, select your App server, then stop this service. 2) DNS entries are the way to target a WFE for end user access. End users will only go to the WFE DNS is pointed at (or if DNS is pointed at a VIP, to the ...


5

You could create a new web application named how you want and then attach the content database(s) from your old web application in order to keep your existing sites. Its not really renaming the old web application but you will be able to access your old sites via the new url which I assume is what you want to do. The basic steps are: Check what site ...


5

If you are limited by Memory, you can share the same App Pool between several Web applications. This will allow you to save some memory. Sharing AppPools will allow you to pool that "base" memory per app pool. The total amount of requiered RAM cannot be dertermined by just the number of WebApps, but is also affected by many other factors. A valid reason to ...


5

There are so many better ways to improve the performance and scalability of SharePoint than trying to partition site collections across web applications. If you highly optiimize your logical and physical disk IO for SQL Server, partitioning the site collections across multiple content databases on a single web application may provide less contention and ...


4

The advantage of multiple managed paths is it's a first piece of metadata you can have in your farm. It helps break sites out into logical trees even thought they all reside in the same farm. This becomes very beneficial if you organize your structure very flat (many site collection) Based on the managed paths, you can have different SLAs for things ...


4

Many points can be taken in consideration while choosing web application or site collection. Some important ones are: 1) Web application provides isolation. If your web application uses a unique application pool in IIS, the isolation is at Process level. If your web application uses a shared application pool in IIS, the isolation is at Application Domain ...


4

Can't test it myself but it wouldbe something like this: ######################## Start Variables ######################## $LoginName = "domain\login" $siteURL = "http://SharePointSiteURL" #URL to any site in the web application. ######################## End Variables ######################## Clear-Host $siteCount = 0 ...


4

If you are going to get the property bags of your web application or farm OFTEN, you could create a custom HttpHandler to create a dynamic javascript file which will load the properties you want. See my blog post about how to create an httphandler. The idea is partly inspired from loading _spPageContextInfo If you think it is the way to go, I can tell more. ...


4

You have to Create a Site Collection in your Web Application. Go to Central Administration and choose Create Site Collection in the Application Management group. Enter a title in your Site Collection, select template to use and the primary site collection administrator: This can be done using PowerShell as well. Don't forget to Set Execution Policy ...


4

When you create the Web Application you decide what should be the URL of it. And in your setup it should not be the URL of any of your servers, but the URL for the load balancer which distributes the work between wfe01 and wfe02. And normally you'll leave the web application service running on the App server as well and let Search Crawl use that locally by ...


3

you can only use sharepoint's server side api on the server sharepoint is running on. for communication from another machine to sharepoint you need to use the webservices or, if you are running SP2010, the client framework. Edit: If you try to access an url from the server itself through a hostname other than the real machine name it might be the ...


3

The thing to remember is that on x64 systems, an app pool can consume a lot of memory, if unchecked, 1GB+. On x86 systems, ASP.NET is capped at 900MB by default. Setting a memory cap is useful, but will cause the app pool to recycle if the app tries to go over it, basically bringing your app down for a few seconds. If bad code (Undisposed SPSite objects ...


3

So could you clarify - you want both web applications to use the same host header? This is not possible but if you want the new web application to use www.abc.com and the old one to respond to a different host header (www.oldabc.com) this can be achieved. Is this what you are after? The basic steps are: Create a new host header based web application ...


3

I am not a big fan of mixing the two, but it can be done. My preference is to either integrate and deploy the app to SharePoint or run it on a separate web application in IIS. The request handling process was rewritten with 2007 so there is no longer an "excluded paths" option in the Managed Paths section. If you create a folder in the root of the web ...


3

You'll want to use client side code like the Client Side API or Web Services for connecting to SharePoint just like silverlight. XBAP is only for IE/Firefox XBAP requires the correct version of .net preinstalled XBAP must be installed onto client computer Can run full trust **XBAP is installed on first access and re-installed/updated if the XBAP changes ...


3

I've seen some organizations use a single site collection to hold everything, and create more site collections than they need so they struggle with administration and maintenance. Both of those extremes can be bad. It is really about trying to find the sweet spot for how your sites will be used and maintained. Awhile back I wrote a pretty detailed blog ...


3

Here's a couple of options for you: In Central Admin, go to your Search Service Application (Content SSA if you use FAST Search for SharePoint) then navigate to Server Name Mappings and create one. Set the "Address in index" field value to your Extended zone url (the one configured to be crawled in the content source) and set the "Address in search ...


3

Since this is a separate web application, you can still use port 80 and specify http://board in your host header. This will work as long as your existing http://portal site is also using only the host header and not the wildcard * where it intercepts all requests to port 80. As Moss Farmer mentions, you will need to define your Alternate Access Mappings so ...


3

My recommendation would be that you shouldn't. You should start from scratch again and develop your Web-Application to be deployed below the _layouts folder in SharePoint using a WSP package and all of your code should be in code behind which is compiled into a dll deployed to the GAC. You can technically get your solution to work, but it's a hack, that ...


3

Depends on what you mean by sharing, they will be sharing the same website in IIS, the same web.config, the same content database by default, the same web application settings in Central Admin etc etc. You can configure site collections to be under different host headers if you wish. What are your requirements? Would you prefer each customer to be accessing ...


3

Your scope for feature is at "Web Application" level feature and therefore be visible at Central Administration -> Application Management -> Manage Web Application Features See technet Edited You can activate Web Application Feature by giving it's url. stsadm -o activatefeature -id GUIDID -url https://abc303.development.com/ If you're facing ...


3

As far as I know or according to my experience you should be creating Site Collections for departments and let each department have there own content database as a best practice. Web applications should be created on the basis of mode of authentication. I would recommend you to go through these topology diagrams provided by Microsoft to understand the ...


3

In case this helps anyone else (or me in the future) you can do this with: $winAp = new-SPAuthenticationProvider -UseWindowsIntegratedAuthentication $stsAp = Get-SPTrustedIdentityTokenIssuer "YourSTS" Set-SPWebApplication -Identity $webApp -AuthenticationProvider $stsAp, $winAp -Zone "Default"


3

If your web application is in Claims mode (uses Claims based authentication, CBA), you need to grant permission for username that is in claims format, like i:0#.w|dev\administrator. More info here.


3

First, get all your web applications and iterate through them. While in the loop print web application name and application pool name. Last, iterate all solutions and print their names - like this: $contentWebAppServices = (Get-SPFarm).services | ? {$_.typename -eq "Microsoft SharePoint Foundation Web Application"} foreach($webApp in ...


3

You can`t. The Client Object Model (CSOM) does not provide access above the Site Collection level. As far as I know, the only way to do what you want is to create a custom web service that gets the Web Application information using the Server Object Model and have the remote application use it instead of the CSOM.


3

The RSViewerPage.aspx is a Out the boxed application page in the _Layouts folder. Application pages, which are also known as "_layouts" pages, are stored in a site's Microsoft Internet Information Services (IIS) virtual directory and support application implementations. Application pages are shared across all sites on the server, whereas a site ...



Only top voted, non community-wiki answers of a minimum length are eligible