UPDATE:
To answer a recent comment...I found the following information but it didn't work.
Go to Programs and Features in the control panel.
Find the "Microsoft Web Deploy 3.0 Setup"
Right click the program and click "Change".
Out of the three options, choose "Change" from the "Change, repair, or remove installation menu."
Under the IIS Deployment Handler, there is an option that is usually unchecked, "Configure for Non-Administor Deployments". Check this option and click next.
Finish installation.
This sets up additional options under the management delegation UI that should allow non-admin accounts to deploy to your application. It works on one server but not another. I ran out of time trying to get this to work. My other solution was to do this:
Builds are managed by a dedicated team. We restricted the "View/Edit Build Definitions" on all projects in TFS.
We let the build accounts remain as ADMINS.
We kept the passwords in the definition.
Both solutions work, but I do prefer to the former. One day I'll figure out the difference between the two servers and post another update.
Reference: http://workinghardinit.wordpress.com/2011/07/18/wdeployconfigwriter-account-issues-trouble-shooting-web-deploy-2-0-with-lessons-learned/
Going on three days of troubleshooting - I am officially stumped.
Error Details from TFS Build Log
MSDeployPublish:
Start Web Deploy Publish the Application/package to https://XX.XX.XX.XX:8172/msdeploy.axd?site=Default%20Web%20Site ...
Starting Web deployment task from source:package(D:\Builds\Sources\ProjectA.zip) to Destination:auto().
Updating setAcl (Default Web Site/Test).
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): error : Web deployment task failed.((2/19/2013 9:58:23 AM) An error occurred when the request was processed on the remote computer.) [D:\Builds\Sources\ProjectA.csproj]
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): error : [D:\Builds\Sources\ProjectA.csproj]
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): error : (2/19/2013 9:58:23 AM) An error occurred when the request was processed on the remote computer. [D:\Builds\Sources\ProjectA.csproj]
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets(3847,5): error : The server experienced an issue processing the request. Contact the server administrator for more information. [D:\Builds\Sources\ProjectAcsproj]
Publish failed to deploy.
Done Building Project "D:\Builds\Sources\ProjectA.csproj" (default targets) -- FAILED.
Done Building Project "D:\Builds\Sources\ProjectWeb.csproj" (default targets) -- FAILED.
Build FAILED.
I have three environments. Development, QA and Production
Development and QA has a non-production build account. Production has a production build account.
The deployment works on one of the production servers and on all of the development and QA servers. But not the other. These are separate servers that host different web applications. It is not load balanced or part of a web farm.
I believe this is a permission issue but this issue only exists on one of the servers. To get this deployment to work, I have to setup the production tfs build account on the box as an administrator. Or GRANT FULL CONTROL to EVERYONE on the web application folder. Neither of which are preferred. Not to mention none of the other servers are setup that way.
During the deployment I did notice the ACL permissions are wrong during the first steps of deployment. The web application folder is granting the build account special permissions. While on the other environments, that permission never gets set. I have no clue why this is happening. Perhaps it is an immediate step in the workflow, but I am not certain.
All feature delegation options are setup according to this website. I know they are correct, because I have implemented it several times now. What isn't specified in the link is allowing the build account on the feature rules. All of that is set from the application to the top level site.
If I switch the QA build in TFS to deploy to production it fails with the same issues. So it isn't the build definition. If I grant admin or everyone rights then it works so it isn't the project or configuration.
MSBuild Arguments
/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=WMSVC
/p:MSDeployServiceUrl=https://XX.XX.XX.XX:8172/msdeploy.axd
/p:DeployIisAppPath="Default Web Site/Test"
/p:UserName=DOMAIN\ProdBuildAccount /p:Password=*******
/p:AllowUntrustedCertificate=True
The deployment is kicked off from Team Explorer after queuing a successfully build.
Also if I take the package.zip and import it manually into IIS then the ACL's are correct and it deploys perfectly.
Related
I'm working with WSO2 Identity Server and I'm curious if there is a way to run the product in developer mode without building each component of identity server. I found a way to start the "My Account" component in dev mode by following this tutorial ( https://is.docs.wso2.com/en/5.11.0/develop/setting-up-my-account-in-a-dev-environment/ )
but I want to be able to modify different components such as recovery-portal and authentication-portal by forking and cloning the required github repositories and starting the entire app in developer mode in order to see the code changes in real-time.
AFAIK the developer mode will work only for the MyAccount and Console. You can refer to the doc for more details on that.
The recovery portal, the authentication portal etc. cannot be tried with the developer mode. However, there are two ways that you can try this.
Build the war files manually and add them to the WebApps directory. If the server is running, war file changes will automatically get deployed. If the server is not running, you have to delete the existing directory and restart the server.
You can do the changes to the JSPs that are deployed inside the pack. Once the changes are done, you can save the changes and the changes will automatically get deployed.
I have deployed a Django app to Azure through Github actions to Azure app service. But it gives a Server error 500 everytime. I have configured the static files and react template properly. In the Diagnose tab there's no error is displaying. How can I troubleshoot and find the error or Is there any other things to configure in Azure? I hosted a same copy in Heroku and it works there.
Make sure you are using the below steps:
SCM_DO_BUILD_DURING_DEPLOYMENT=true – With this setting set to true - Kudu will execute build steps on your site during deployment.
DEBUG = 0 - please check (if this can make any change) after adding this config to your configuration.
You need to enable the Detailed error pages in your portal. This may give a detailed log to know why it happened.
Try Adding Application Insights to your App to check the detailed logs
Best practices to deploy your Application
Refer here Link 1 & Link 2
I've played with Microsoft Bot Composer and have checked the extensibility points but it looks like it is not possible to deploy the bot to other clouds.
Please confirm my assumption.
My goal is to achieve deploying without additional development if possible.
Deploying a Composer bot is somewhat more complicated than deploying an ordinary Bot Framework bot because the Composer bot is not stored anywhere in a deployable state. Composer must bundle your specific Composer project files together with the centralized Composer runtime in order to create a deployable package.
However, Composer does come with a way to convert your Composer project into an ordinary bot project that can be deployed just like any web app. This is called exporting (or ejecting) the runtime. You can find out how to do that here.
To export your bot runtime:
Navigate to the Project Settings page of your Composer and find the Custom runtime section.
From the Custom runtime section, toggle Use custom runtime then select Get a new copy of the runtime code.
In the pop-up window select C# and select Okay. A copy of your bot's runtime will be added to the bot's project folder and can
be accessed in the following directory: C:\Users\UserName\Documents\Composer\bot\runtime.
Summary:
I have an Office 365 E3 account where I'm trying to deploy a Word task pane app that will read some SharePoint list data. Right now, I'm just trying to get the task pane app to load, however, it shows the Office 365 login page (in the pane) but does not do anything after clicking Login.
Details:
I went through the instructions provided here:
http://msdn.microsoft.com/en-us/library/office/fp179815.aspx
Basically, I create an App for SharePoint configured as SharePoint-hosted, then in the same project, added an App for Office (Task Pane App for Word only). The SharePoint app also has a custom document library.
I am able to install the app to my App Catalog, and it correctly shows up in Site Contents where I see it being provisioned to the app web. I can also launch Word 2013 with the Trusted App Catalog configured correctly, and I am able to see my Task Pane App and insert it. When I click Insert, it loads it but prompts for credentials.
I am using the same credentials all throughout this exercise so by virtue of being able to install and deploy the SharePoint app, you can trust that I'm providing the right credentials.
It also appears the custom document library is never created - I wonder if both suffer from the same underlying issue.
I encountered the same problem and the solution provided in the answer below did not help.
After some desparation i created a taskpane app using the Napa Cloud App, opened the application in Visual Studio and went looking for differences.
In the Taskpane app manifest.xml file i found the following entries which were missing in my own application manifest:
<AppDomains>
<AppDomain>https://login.microsoftonline-int.com</AppDomain>
<AppDomain>https://login.microsoftonline.com</AppDomain>
</AppDomains>
This solved my problem and cured one horrible friday.
I was able to get this to work. It turns out doing a Deploy from Visual Studio (whether you right-clicked Deploy or F5-debug), the installation of the app isn't enough.
To make it work, I skipped doing a Deploy all together, but instead published my app. I then took the .app file and loaded it in my App Packages folder, and then deployed it from there.
Unfortunately, I don't know the difference between the two, but I'm assuming it has something to do with provisioning the app web for the Office App.
I'm using PowerBuilder Classic 12.1 to deploy a .NET Web Services target to IIS 7 running on my local machine. I'd like to be able to debug it. The documentation from Sybase says I should be able to. But when I run the debugger it says "Attaching to ASP.NET worker" and "Time left: 20 seconds". It counts down to 0 and then I see "Failed attaching to ASP.NET worker process."
I'm running PowerBuilder as an administrator, so I don't think that's the problem.
Suggestions?
Open your your project object that you are using to deploy with. If you have multiple project objects, then right click on your target in the tree-view painter and click preferences to open a dialog that let's you choose which target object will be used for deployment. Choose the one that is set with DEBUG symbol on and set to debug build.
I have had good luck debugging PB Web Services both IIS hosted and self-hosted.
I also found this in the PowerBuilder help file for you:
Using the DEBUG symbol
If you used the DEBUG conditional compilation symbol in code for the nonvisual objects you deploy as a Web service and you want this code to run, you must make sure that the enable DEBUG symbol check box is selected before you deploy the project. If you plan to debug the assembly or Web service, you should make sure the project is deployed as a debug build.
** added additional details here on 1-26-13
This blog article will help you get WCF debugging to work in PowerBuilder.NET.
Testing & Debugging PowerBuilder.NET WCF Web Services