I have a preexisting deployment process which successfully deploys a site to its staging environment. Attempting the same process against a new production environment is failing at the point where we try to invoke msdeploy's "runCommand" option.
We're using pstrami, which ultimately uses msdeploy twice. msdeploy successfully copies files to the target machine. pstrami then tries to use msdeploy a second time, this time to use "runCommand" on a bat file that should actually install everything under IIS.
The first use of msdeploy works, copying the files. Therefore, the credentials we're working with are correct.
The second use of msdeploy outputs the following:
Info: Updating runCommand (bootstrap.bat).
Warning: Access is denied.
It appears that bootstrap.bat is not actually reached. It is unclear who is being denied access to what. I suspect that the user is not allowed to perform "runCommand", but advice about runCommand online is inconsistent and has not revealed anything different between my staging and production machines.
What should it take for msdeploy 'runCommand' to be granted access?
MSDeploy supports configuring permissions on a per-provider basis, so your hosting provider may have disabled it. It might be worth checking with them.
Related
My Elastic Beanstalk installation won't deploy through Visual Studio due to this error:
2016-07-01 20:45:02,627 ERROR 1 AWSBeanstalkCfnDeploy.DeploymentUtils - Exception during deployment.
Microsoft.Web.Deployment.DeploymentDetailedClientServerException: Web Deploy cannot modify the file 'msvcr100.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
The link suggests that I create a pubxml file with settings to enable AppOffline, but this file only seems to be relevant for publishing through VS using the built-in Publish feature. I haven't found any documentation suggesting that this will work for AWS.
How do I enable AppOffline for an Elastic Beanstalk deployment?
Thanks!
Sorry that this is only general advice and not the code you need, but the solution is to use hooks via .ebextensions. Please see http://docs.aws.amazon.com/codedeploy/latest/userguide/app-spec-ref-hooks.html.
You can add the execution of a powershell script to add app_offline.htm before the update is extracted and remove it once the update is deployed.
We had a similar issue, but the DLL in question (abcPDF, v9) was only blocked because we were initializing the licensing of it during application_start(), which EB did not like. So we moved applying the license elsewhere.
However, I think this approach would work.
--
Oh, maybe this container command will work for you. It recycles the IIS app pool right before the It didn't for us because of the aforementioned licensing locking the DLL.
/.ebextensions/recycleapppool.config
container_commands:
__recycle_app_pool:
____command: c:\windows\system32\inetsrv\appcmd.exe recycle apppool DefaultAppPool
After quite a lot of experimentation, the only working solution I could find for this problem was
// in Project/.ebextensions/reset.config
container_commands:
00_nuke:
command: IISReset
waitAfterCompletion: 0
The cost was about 4 seconds of downtime (on a t2.micro), during which you get a 503, which certainly isn't great.
Note there's a Github issue for this (open at the time of writing).
If you have the option, deploy your service to Azure rather than AWS and there are configuration options to work around the issue (such as an environment variable MSDEPLOY_RENAME_LOCKED_FILES) - related Azure specific question.
I am using WebDeploy (msdeploy.exe) to deploy an ASP.NET Core app to an Azure App Service instance.
This works fine most of the time, but sometimes the deployment fails with the error message: Unable to perform the operation ("Create File") for the specified directory. (...) ERROR_INSUFFICIENT_ACCESS_TO_SITE_FOLDER.
I believe this is some file locking issue, because the only way out of this is to log into Azure Portal and stop the App Service, and then redeploy. After this, deployment is fine for a while, until the same happens again.
Having spent some time setting up automatic deployment, this hickup is very annoying.
Is there any way around this issue?
It has nothing, as i understand, with the Azure - the error is a bit common.
As for Azure Web Apps, there are two options:
1) Stop your site and deploy.
2) If the first one is not OK, then use Kudu Console, find your file (for example, d:\home...\something.blocked) and rename the file. After that, the problem should be away
If that is the helpful answer, please mark it as a helpful or mark it as the answer. Thanks!
We are using Tridion 2011 SP1. Some of the pages/components are getting failed while publishing with below mentioned error.
Phase: Deployer Prepare Phase failed, Unable to unzip,
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process),
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process), Unable to unzip,
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process),
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process)
Components/Pages are failing under stage Preparing Deployment, how should we fix it?
Do you have multiple Deployers using the same incoming location?
It looks like you’re running the Deployer as a WebApp – is the Deployer service also running on the system?
If you search for all files named “cd_deployer_conf.xml”, do they have the same incoming folder (D:\Inetpub\TridionPublisherFS4SP\incoming) defined?
Otherwise, you might use ProcMon to watch the folder and see what else is accessing the file.
If you still have this issue, you may try
1. deleting all files under incoming,
2. making sure there is no encryption enabled for the incoming folder (Some companies apply encrypt script immediately to the files that are added to the drive) or
3. making sure your antivirus is not screening that folder (As Nuno mentioned).
Do a restart of the deployer app and verify in the logs?
Is it possible to deploy the contents of a folder (plain Html files) to a specific web application on a remote IIS6/7 server?
The following command does not error, but neither does it publish any files to the remote server:
msdeploy.exe -verb:sync -source:dirPath="c:\myHtmlFiles" -dest:auto,ComputerName="http://deploy.mycompany.co.uk/msdeploy?site=TestSite",includeAcls="false",username="administrator",password="myPassword" -enableRule:DoNotDeleteRule -disableLink:AppPoolExtension -disableLink:ContentExtension -allowUntrusted
NOTE:
WebDeploy is correctly installed on the destination server and works happily with packages created from msbuild scripts for .NET projects.
'http://deploy.mycompany.co.uk/msdeploy' is correct for the listening end-point.
The '?site=TestSite' query string was suggested elsewhere, but does not work.
The 'TestSite' web application exists on the target server.
Parameter files and -setParam do not work, and renders errors relating to the source not supporting the parameter 'IIS Web Application Name' if you attempt to set, declare, or provide it.
I just wrote a blog post to answer this at http://sedodream.com/2012/08/20/WebDeployMSDeployHowToSyncAFolder.aspx. From your question it looks like you are pretty familiar with MSDeploy so the answer might be a bit verbose but I wanted people with less knowledge of MSDeploy to be able to understand. I've pasted the answer below.
Web Deploy (aka MSDeploy) uses a provider model and there are a good number of providers available out of the box. To give you an example of some of the providers; when syncing an IIS web application you will use iisApp, for an MSDeploy package you will use package, for a web server webServer, etc. If you want to sync a local folder to a remote IIS path then you can use the contentPath provider. You can also use this provider to sync a folder from one website to another website.
The general idea of what we want to do in this case is to sync a folder from your PC to your IIS website. Calls to msdeploy.exe can be a bit verbose so let’s construct the command one step at at time. We will use the template below.
msdeploy.exe -verb:sync -source:contentPath="" -dest:contentPath=""
We use the sync verb to describe what we are trying to do, and then use the contentPath provider for both the source and the dest. Now let’s fill in what those values should be. For the source value you will need to pass in the full path to the folder that you want to sync. In my case the files are at C:\temp\files-to-pub. For the dest value you will give the path to the folder as an IIS path. In my case the website that I’m syncing to is named sayedupdemo so the IIS path that I want to sync is ‘sayedupdemo/files-to-pub’. Now that give us.
msdeploy.exe –verb:sync -source:contentPath="C:\temp\files-to-pub" -dest:contentPath='sayedupdemo/files-to-pub'
For the dest value we have not given any parameters indicating what server those command are supposed to be sent to. We will need to add those parameters. The parameters which typically need to be passed in are.
ComputerName – this is the URL or computer name which will handle the publish operation
Username – the username
Password – the password
AuthType – the authType to be used. Either NTLM or Basic. For WMSvc this is typically Basic, for Remote Agent Service this is NTLM
In my case I’m publishing to a Windows Azure Web Site. So the values that I will use are:
ComputerName: https://waws-prod-blu-001.publish.azurewebsites.windows.net/msdeploy.axd?site=sayedupdemo
Username: $sayedupdemo
Password: thisIsNotMyRealPassword
AuthType: Basic
All of these values can be found in the .publishSettings file (can be downloaded from Web Site dashboard from WindowsAzure.com). For the ComputerName value you will need to append the name of your site to get the full URL. In the example above I manually added ?site=sayedupdemo, this is the same name as shown in the Azure portal. So now the command which we have is.
msdeploy.exe
–verb:sync
-source:contentPath="C:\temp\files-to-pub"
-dest:contentPath='sayedupdemo/files-to-pub'
,ComputerName="https://waws-prod-blu-001.publish.azurewebsites.windows.net/msdeploy.axd?site=sayedupdemo"
,UserName='$sayedupdemo'
,Password='thisIsNotMyRealPassword'
,AuthType='Basic'
OK we are almost there! In my case I want to make sure that I do not delete any files from the server during this process. So I will also add –enableRule:DoNotDeleteRule. So our command is now.
msdeploy.exe
–verb:sync
-source:contentPath="C:\temp\files-to-pub"
-dest:contentPath='sayedupdemo/files-to-pub'
,ComputerName="https://waws-prod-blu-001.publish.azurewebsites.windows.net/msdeploy.axd?site=sayedupdemo"
,UserName='$sayedupdemo'
,Password='thisIsNotMyRealPassword'
,AuthType='Basic'
-enableRule:DoNotDeleteRule
At this point before I execute this command I’ll first execute it passing –whatif. This will give me a summary of what operations will be without actually causing any changes. When I do this the result is shown in the image below.
After I verified that the changes are all intentional, I removed the –whatif and executed the command. After that the local files were published to the remote server. Now that I have synced the files each publish after this will be result in only changed files being published.
If you want to learn how to snyc an individual file you can see my previous blog post How to take your web app offline during publishing.
dest:auto
In your case I noted that you were using dest:auto, you can use that but you will have to pass in the IIS app name as a parameter and it will replace the path to the folder. Below is the command.
msdeploy.exe
-verb:sync
-source:contentPath="C:\temp\files-to-pub"
-dest:auto
,ComputerName="https://waws-prod-blu-001.publish.azurewebsites.windows.net/msdeploy.axd?site=sayedupdemo"
,UserName='$sayedupdemo'
,Password='thisIsNotMyRealPassword'
,AuthType='Basic'
-enableRule:DoNotDeleteRule
-setParam:value='sayedupdemo',kind=ProviderPath,scope=contentPath,match='^C:\\temp\\files-to-pub$'
I have a production website that, once built in TFS is re-deployed and updated using xcopy. The entire site (excluding the root directory) it deleted then the new site copied in. This works well.
We use a 3rd party charting package that creates images at runtime and then renders a link to them. In order to do this it needs write permissions to a browsable folder.
Unfortunately, every time we update the website the write permissions of IIS_USRS is lost. Is there any way to retain this?
I guess it depends on what operating system the server is running, and whether you are building on the same server as you're deploying to, or a remote one.
The simplest thing to do is to put your xcopy command into a batch file, and include something like the following after the xcopy:
cacls c:\[PathToWebsite]\[ChartImagesFolder] /E /G [AccountSiteRunsUnder]:C
Or a more up to date option (I've not used this, so my parameters may be off):
icacls c:\[PathToWebsite]\[ChartImagesFolder] /grant [AccountSiteRunsUnder]:M
Basically, either of those should give the user account that the site is running under modify (change) rights in the folder specified. This should be in addition to any existing rights on the folder, there are modifiers or switches to replace the existing rights.
If you are deploying to a remote server, you'll need some mechanism to run commands on there, we've found that PSExec works a treat (part of the PS tools from SysInternals).