I need to migrate multiple IIS sites from one server to another. The problem here is that the target server already has IIS installed and some other sites running on it. All the solutions described in search results are unacceptable – they will replace everything basically doing a full wipe of the existing sites. Is there any way to create an "additive" migration package?
You can use msdeploy.exe to sync individual sites between servers.
msdeploy -verb:sync -source:webServer -dest:webServer,computerName=Server2
https://technet.microsoft.com/en-us/library/dd569005(v=ws.10).aspx
Related
I have recently been trying to migrate some websites from a 2003 server with IIS 6 to a 2012 server with IIS 8 installed. I am using Microsoft's Web Deploy tool and have been successful in copying a few web sites one at a time using the following command (changing the site identifier # for each site).NOTE: The reason the mumbo jumbo with replacing the drive exists is because our new server has a different data drive on it, and MSDeploy didn't like that. Could that be breaking things as well?
msdeploy -verb:sync -source:metakey=lm/w3svc/#,computername=SourceServerNameHere -dest:metakey=lm/w3svc/# -replace:objectName=metaProperty,scopeAttributeName=name,scopeAttributeValue=Path,targetAttributeName=value,match="F:",replace="E:" -enableLink:appPoolExtension > migration.log
The main issue is that when I try to navigate to any site one of three errors happens..
1. 503 Service Unavailable
2. 401.2 Unauthorized
3. 404.17 Not Found
These errors start from 1, and progress to 3 as I am trying to troubleshoot the IIS configurations. But this kind of defeats the purpose of using the Web Deploy Tool. Has anyone had any luck migrating sites being completely successful, or does the tool not actually support "IIS 6.0 or higher migration?"
Thanks in advance.
EDIT: So I have been able to get the main page of my site working by reverting the Handler Mappings and Default Documents to their parent configurations, and making sure that the AppPools don't conflict with versions, etc. The problem with this, is that I have to figure out how to do this for every app and app pool under the sites... Does anyone else have a similar problem?
Try using the iisApp provider instead of the MetaKey provider. For example,
msdeploy -verb:sync -source:iisApp=Site1/ContosoApp,computerName=Server1 -dest:iisApp="Site1/ContosoApp",computerName=Server2
https://technet.microsoft.com/en-us/library/dd569054(v=ws.10).aspx
I ended up contacting Microsoft Support to get this sorted out and ended up spending 3 hours on the phone with them...There were multiple issues that came up during the deploy tool's migration.
The bulk of the issues were corrected by changing the application pools to 64-bit and commenting out abomappercustom handlers in the applicationhost.config.
I want to install multiple Sitecore instances to be hosted under one domain. So the root url of first instance will be http://example.com/instance-1 and so on.
The reason I want to have multiple instances is that, I want to split environments for each site. I know I can play with bindings and publish each instance on other port within same domain. I also know that I can install multiple sites under one instance. But I didn't found solution how to install instance in IIS site subdirectory.
Please if anyone was successful instaling multiple instances as child application or virtual directory, please share the knowledge.
I'm using Sitecore 6.5 and IIS 7.5
Sitecore does not support running in virtual directories.
It must run in its own website.
However, i did come up with a trick, but it is quite advanced and i don't have clear cut examples:
Setup one site that will be your main domain with sub folders (eg.
www.mydomain.com/site-a , www.mydomain.com/site-b
Setup your separate Sitecore instances as separate IIS websites
Give each site its own hostname and add it to your hosts file (so you get http://site-a, http://site-b, etc)
Install the IIS URL Rewrite feature, make sure rewriting of the HTTP_HOST server variable is allowed
Configure rewriting on your main site, so that http://www.mydomain.com/site-a/* is rewritten to http://site-a/*
Create a custom linkprovider that makes sure Sitecore links are being written using the correct domain and folder (so http://site-a/item is written as http://www.mydomain.com/site-a/item)
I'm sure this is possible as i've implemented a similar solution for a site that hosted clones if a site as 'virtual' folders.
I wonder why you have the need to host multiple Sitecore instances on the same domain. Sitecore has good solutions for multi site setup in the same instance. If the solution Ruud provided is not workable for your, check the multi site solution of Tim Ward ( https://github.com/jerrong/Sitecore-Multisite-Manager ) or the shared source module on the Sitecore Marketplace ( http://marketplace.sitecore.net/en/Modules/Multiple_Sites_Manager.aspx )
In short, I have three servers in a web farm, one of which is configured as a State Server. Two of the servers (including the State Server) are correctly sharing session state, but the other server is holding it's own session still.
Here's what I've done:
I have modified the web.config.comments file on all three servers so that they have the same machineKey entry.
On the State Server, I have changed the AllowRemoteConnections registry entry to 1. I then set the ASP.Net State Service to start automatically and switched it on.
The web site is configured on all three servers and the root site shares the same Identifer in IIS. Each configuration is identical. The website itself is contained on a network share, so the same web.config file is used on all three servers. I changed the sessionState entry in the web.config to point to Web3.
So Web2 and Web3 are able to set/modify/destroy the same session, but Web1 is still running with it's own.
I'm at a loss here after hours of Googling, so any help is greatly appreciated.
This application is configured a few subdirectories into the root site. Is there a separate AppID at this level? If so, how can I find it?
Thanks,
Aaron
http://support.microsoft.com/kb/325056
To maintain session state across different Web servers in the Web farm, the application path of the Web site (for example, \LM\W3SVC\2) in the Microsoft Internet Information Services (IIS) metabase must be the same for all of the Web servers in the Web farm. The case also needs to be the same because the application path is case-sensitive.
On one Web server, the instance ID of the Web site where the ASP.NET application is hosted may be 2 (where the application path is \LM\W3SVC\2). On another Web server, the instance ID of the Web site may be 3 (where the application path is \LM\W3SVC\3). Therefore, the application paths between Web servers in the Web farm are different. For additional information about how to check the application path of the Web site, click the following article number to view the article in the Microsoft Knowledge Base:
240225 Description of Adsutil and MetaEdit Used to Modify the Metabase
This is not really answering your question, but in my experience the ASP.NET session state service is not something you should scale to more than one server. It doesn't perform very well (especially under load) and is difficult to configure. I found that a distributed cache such as memcached is much simpler and faster for this purpose.
Have a look at this project.
matthewk's answer actually turned out to be almost the correct one. Over a year later I've returned to this and found the answer. Though probably correct, I felt that if the answer above had been more specific I would have solved this!
I searched through the MetaBase.xml file (C:\WINDOWS\system32\inetsrv) for the web application. After a game of spot the difference I noticed that there was a slight difference in the following line:
<IIsWebVirtualDir Location ="/LM/W3SVC/103071637/root"
AccessFlags="AccessRead | AccessScript"
AppFriendlyName="Default Application"
AppIsolated="2"
AppRoot="/LM/W3SVC/103071637/Root"
...
Specifically, the AppRoot (not the Location) on Server 1 had a Proper-Case "Root" whereas Server's 2 and 3 had "ROOT" all in caps. I updated Server 1 to match and restarted IIS and it works a treat.
ie.
AppRoot="/LM/W3SVC/103071637/Root"
AppRoot="/LM/W3SVC/103071637/ROOT"
I am having non uniform results for applications running on two Windows 2003 Servers running IIS. Is there a way to quickly dump IIS configurations to a file for comparison? Are there good tools to compare two IIS servers?
Give Metabase Explorer a shot as part of the IIS 6 resource kit. You can view all the settings for multiple servers and copy/paste the results to an xls and compare there.
You could use Web Deploy (http://www.iis.net/download/WebDeploy) for that, you can point it to the server remotely (assuming you have Administrator credentials) and diff two servers to see what are the differences. You could even sync them if you wanted to so that they look the same.
So I figured out that by adding the ResetWebServer="FALSE" attribute to the solution manifest prevents SharePoint from recycling any app pools.
However, when upgrading a solution that originally did not specify ResetWebServer="FALSE" or when retracting a solution that does specify ResetWebServer="FALSE", the application pools are still being recycled. Is there a way to prevent any auto-recycling of app pools?
This does not seem possible given the document on MSDN (see below), note that I included Deploying a Solution over Upgrading a solution as underneath it is effectively doing a file replacement. I believe the restart/recycling is necessary as a result of how IIS functions. An option to explore if you wanted to manage when this occurs is to ensure that all deployments are done via timer jobs and execute when their impact will be minimized.
Deploying a solution
Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).
Retracting a solution
On each front-end Web server, the following occurs:
Microsoft Internet Information Services (IIS) is disabled.
Files are removed from the system.
IIS is re-enabled and Windows SharePoint Services is reloaded when
a user browses to a page.
You might also take a look at the "-local" switch. Didn't try it yet but it seemed that it allowed deployment server per server when you are in a load balanced situation.
Might be a good lead.