I would like to update the Diagnostic configuration file for the azure roles whenever I upgrade my deployment. How can I do this automatically?
From time to time, we do change our diagnostic (using code) - and upgrade the service. But whenever we upgrade the service, it is still using the old diagnostic configuration and we do not see any new logs we have configured using new code.
How can I achieve this so that whenever I upgrade my deployment, it upgrades the diagnostic configuration as well.
I wonder if you have a bug in your diagnostics updating code. If each role ran code in OnStart or Run to configure diagnostics on startup, there would be no reason that your instances wouldn't be properly configured. I tend to think that imperative code that configures diagnostics is inherently a bad idea in the long run, but it should still work. If you share the code, maybe I can spot an issue.
The best** way I have found to update and enforce configuration is to use the diagnostics.wadcfg file and update it. When you upgrade your deployment, it will use those settings if you have not overridden it in code somewhere. Contrary to Microsoft's guidance at that link, it should be the preferred method as opposed to code which must be maintained and is orthogonal to your application's purpose. Said another way - a declarative configuration file that your ops team can maintain over writing code is usually a better idea. To use this, just include it in your deployment as content and delete any existing files in wad-control-container (and remove any code that configured diagnostics). It will just configure itself from that file then when you next upgrade.
** you can also using a 3rd party SaaS monitoring to set and maintain your diagnostics config. I work on one such one, but I am guessing you want to know how to do it yourself. :)
Related
As far as I know, regarding web-roles, it is possible to have multiple ServiceConfiguration.cscfg files, one for each publish profile (for example, Cloud1, Cloud2, Cloud3, Local and so on).
Though, is it possible to have different diagnostics.wadcfg (wadcfgx) files?
How to instruct Visual Studio to use a specific diagnostics file when deploying to Azure? Is there a specific entry in the publish profile XML file?
Out of the box, it is not possible because there can be only one diagnostics.wadcfg (wadcfgx) file associated with a role in a cloud project a cloud project.
We are using SDK 2.4 in our project and the way we have worked around this problem is by creating separate cloud projects for each environment - Dev, Staging, and Production. Since these are separate cloud projects, we can have different diagnostics configurations.
If you're using SDK 2.5, one thing that works in your favor is the diagnostics is now an extension (instead of plugin). What that allows you to do is change/enable/disable diagnostics on the fly. Though I have not tried it but one thing you could possibly do is enable diagnostics as a part of your deployment process. By default there won't be any diagnostics.wadcfgx file in your project. When you deploy your code via PowerShell, after successful deployment, you can enable this extension. Please see Step 4 here: http://azure.microsoft.com/en-in/documentation/articles/cloud-services-dotnet-diagnostics/#worker-role. (Since I have not tried it myself, I would be very much interested in knowing the outcome. Please do share if this approach worked for you).
My question is similar to this one, which remained unanswered, unfortunately.
We are rolling out a web application as a web deployment package (Web Deploy/MSdeploy) to different environments. The package is created from within Visual Studio 2012/Team Build. Several parameters are to be set at install time (connection strings, WCF endpoints, logging settings, etc.). We have these in a parameters.xml at the root of the project.
Most of our customers import the package through IIS UI. Each time we roll out an update, customer IIS administrators have to provide the parameter values again through the UI. Most of the time, parameters do not change across updates.
What is the best way to handle this? Advise customer IIS administrators to use the command-line instead, injecting a SetParameters.xml that they keep separately (the level of some of our customer administrators isn't particularly high, so having something UI-based which we can document with a couple of screenshots is an advantage)? Keep the settings file (web.config or appconfig) out of the package altogether? What is the neatest way to do this?
I had the same problem, but decided to go with the batch-script installer file that comes with the web deploy package. In my mind it is more secure, doing this installation by script, instead of having to install through GUI. It can be documented, and maybe they need to learn a little bit of command-line?
As you say, they can use the same SetParameters-file for all following releases, if nothing in it changed - which in my mind is a huge benifit - not having to manage web.configs manually.
Automated deploys minimizes manual errors.
I've got an existing Umbraco install on Azure cloud services (not Azure web sites), and although the web.config tells me that it should be found at ~/App_Data/umbraco.config, it isn't there.
Does anyone know where this would be stored? Is there a chance it is writing to a db table perhaps?
I need to edit some nodes as I suspect that at least one is owned by a user which no longer exists, hence no nodes at that level are visible in the admin system (JS error).
The site was set up with Umbraco Azure Accelerator, if that offers any clues.
Thanks!
It is worth noting that Umbraco hasn't needed the Umbraco Accelerator for Azure in the latest versions due to the use of Azure Web Sites. I am wondering which version of Umbraco you are running? The Accelerator projects are being deprecated and have ceased updates, as you can see here by the lack of recent updates. You can read more about the reasoning behind this, and about how the Accelerator's functionality is now a part of the Azure core itself, over here.
So - assuming that your site is an old one and you cannot just reinstall it as an Azure Web Site, can you firstly please confirm that you have the config enabled through the following setting in /config/umbracoSettings.config?
<XmlCacheEnabled>True</XmlCacheEnabled>
If this is false (as is best during all hosting environments except live) then we know that Umbraco will not use the cache. Can you please also check that the following section doesn't list any other machine IP addresses in umbracoSettings.config? Note that this is only relevant if the enabled attribute is true as in the example below.
<distributedCall enabled="true">
<user>0</user>
<servers>
...
</servers>
</distributedCall>
Next, we need to check that Umbraco is still set to use the location /App_Data/umbraco.config through the web.config file.
<appSettings>
<add key="umbracoContentXML" value="~/App_Data/umbraco.config" />
</appSettings>
We should consider the way that Umbraco works on Azure and whether it could have any effect on your site. The Umbraco Accelerator used to be necessary to synchronise the umbraco.config file between Azure instances. With each instance running a separate Umbraco website, there has to be a way that they can talk to each other. The accelerator mirrors that cache file between instances.
Assuming that your code is a default install, and not having been worked on by someone else before you, then it could be an idea to reduce your site to a single instance. Now see if it generates the cache after restarting the website. Finally, you can upgrade the site to see if it regenerates the cache.
These issues are usually always caused by some kind of configuration issue. I also remember that you can simulate Azure deployment using the Windows Azure SDK which you can use to examine for signs of the cache. Good luck.
I'm not sure about the Umbraco Accelerator or a non Web Site project, but we currently are running Umbraco on an Azure web site and App_Data\umbraco.config comes and goes when it pleases and the website unexplainably works. I would like to find the reason behind this if anyone has an answer??
I have a web application project in VS2012 which I'm publishing using a "Web Deploy Package". I want this package to include app-pool settings, specifically creating an IIS app-pool and assigning the newly created application to it.
I'm familiar with the option "Include application pool settings used by this Web project" available when the project is configured to use an IIS instance (not IIS Express), but IIS configuration is not part of the project file, and thus not source controlled. What happens when somebody builds a deployment package on a machine that hasn't had IIS meticulously configured? Not ideal.
How else then, can I go about getting AppPool settings into my web deploy package? I understand that the appPoolConfig provider is IIS7+ only, I'm fine with that limitation. I've banged my head against this issue in the past and never found a solution. 18 months later, we've got a new VisualStudio version, and a new web-publishing-pipeline, are there new options to address this? Or maybe something I missed when I first tackled this problem?
Edit
OK, I'm seeing the following as options:
Configure my project to sync settings from an IIS instance. As mentioned, I'm not a fan of this given that it puts settings outside of the project, meaning the environment has to be meticulously configured to build + publish. Plus it drags along other IIS settings I don't want included.
Inject something into the web-publishing-pipeline (WPP) to modify the archive.xml. I've toyed with this in the past and had limited success. One problem is the pipeline isn't exactly co-operative with working directly on the archive.xml file, another problem is some of the more cryptic attributes involved, like MSDeploy.MSDeployProviderOptions which appears to have some Base64 encoded binary? No idea what to put in there.
Find an existing "provider" that can do what I want. I might be out of luck here, the appPoolConfig provider only seems to want to read / write IIS, not, say, an XML file of settings. Does anybody know otherwise?
Write my own "provider" to produce manifest output entries. I'm not sure, is it possible to write a custom provider that writes to a manifest using the name of an existing provider? As in, MyCustomPoolProvider writes appPoolConfig sections into a manifest? This sounds like a potentially painful exercise that may or may not work. Would I still need to figure out the encoding of whatever is going into MSDeploy.MSDeployProviderOptions?
I get the feeling that the fundamental obstacle with Web Deploy for what I'm trying to accomplish, is how strictly it leans on "providers". The pre-existing providers are largely designed for IIS synchronisation, not primary development and publication. It so happens that some of these providers can be relatively easily hooked into via MSBuild, but the majority insist on pulling data from IIS, and that's that.
You are correct in your understanding of the appPoolConfig provider, in that it can only sync between App Pools and can't be provided with the configuration directly. What you could potentially do is keep a copy of the appPool in question in package form (ie. msdeploy -verb:sync -source:appPoolConfig=PoolName -dest:package=apppool.zip) and attempt to hijack the pipeline so that the MSDeploy call adds the application content into the package, leaving the existing content there.
Alternatively, you could always keep the packages separate and deploy them with different calls to MSDeploy.
FYI, MSDeploy.MSDeployProviderOptions is simply an encoded version of the parameters supplied to the provider when it was packaged. For example, -source:dirPath=c:\,ignoreErrors=0x10293847 -dest:package=package.zip would package the ignoreErrors value.
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH