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.
Related
We have wsps in our project.But whenever wsp is deployed the "Service Unavailable" page comes at the site level.
Is there any way that few Dlls can be added in GAC without taking a downtime in production server?
No is the answer in reality. When you do a deployment with a WSP the reset is triggered so the latest dll's are reloaded and to clear down memory within the application pools.
So anything that is related to server side code will require a reset.
If you update anything in the hive you can get away with zero downtime deployment.
There is a more in depth answer here as to when do you need an IISReset
Cheers
Truez
It is technically possible to do a local deployment and stage this yourself. Install-SPSolution offers the local switch. You could in theory use this and control the rotation of the deployment (assuming more than one server). but as noted above to get IIS to reload the assemblies requires the application pool to be cycled. Assemblies are loaded from GAC, but are then memory resident.
https://blog.ithinksharepoint.com/2012/07/16/deploying-sharepoint-wsp-solutions-without-downtime/
I've tried it a few times and not been hugely successful so your mileage may vary.
If you are dependent on GACed Assemblies you can technically push them yourself outside of the WSP. However you may end up in a weird place as the following may occur:
1) You retract the web application from all servers (this will also retract the solution). You may end up with nothing or orphaned assemblies in GAC
2) You add a server later on and it takes the deployment package and you have a server with a different set of bits in your farm. This is painful to troubleshoot for anyone. Imagine if you left?
3) You deploy an assembly and it has a different version than what your web.config expects and it can't be used or found.
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 am trying to use Enterprise Web Library with Windows Azure. It appears that the web.config file for the EWL project works fine locally, but when I deploy to Azure the application cannot initialize. After logging in and viewing the site locally on Azure, it appears there are several web.config elements EWL requires that are locked on Azure. I've had to edit the following in order to have the application initialize on Azure:
Remove <serverRuntime uploadReadAheadSize="8388608" />.
Remove everything nested inside of the modules element.
The application seems to run fine on Azure after removing these parts.
The Web.config elements you removed are important to ensure that EWL works properly: uploadReadAheadSize fixes a problem with client certificate authentication, and using <clear/> in the <modules> section makes the behavior of EWL applications consistent across different servers by keeping the same set of modules in the pipeline regardless of what IIS features are installed on the machine.
There has to be a way to unlock these config sections in an Azure web role. Assuming they are locked in the web role's applicationHost.config file, maybe you can modify this file using a startup script as described in this answer: https://stackoverflow.com/a/10140024/35349.
I am not very familiar with Enterprise Library. If William’s suggestions do not help, please check your web.config to see if you’re missing any configuration sections. On your local machine, when you install Enterprise Library, it may modify machine.config to add certain configurations. But they may not exist in the cloud. So please search your local machine.config to see if there’re any Enterprise Library specific sections, and then add them to your web.config.
Best Regards,
Ming Xu.
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