SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It only takes a minute to sign up.
Sign up to join this community
Is there any good articles out there to explain when we need to do an IISreset after deployment?
We are using SharePoint as an internet facing site, and try to not do an IISreset if it is not absolutely necessary.
For example: - When changing code in a timerjob, is it good enough just to reset the timerjob service? - What about when adding a feature or a new page layout?
There is a fine line of difference between IIS Reset and Web Application Pool recycle when it comes to SharePoint Deployments.
IIS Reset does 2 important things concerning SharePoint -
Web Application pool recycle is concerned with both the above for all IIS websites sharing a single APP Pool.
Considering the above, when you deploy a farm solution whose scope of activation is at the web application level, SharePoint only recycles the application pool of that target web application where the farm solution is to be deployed. In most cases from the perspective of IIS it is just one website.
This is not an IIS Reset. Your all other web applications in SharePoint will continue to work just fine retaining their existing http requests queues and asp.net objects in the app domain.
Coming to your question regarding timer job and page layout changes.
Think of SharePoint deployments in two different categories :-
a) Functional Changes
b) Branding Changes
Predominantly all of SharePoint deployments more or less fall into these two categories.
Functional Changes - These include your farm solutions like timer jobs, webparts, event receivers, custom dlls (like MVC data access layers),etc.
These changes are dll driven and hit the GAC of each server added in the farm. So there is a dependency on web application pool recycle and IIS resets in such deployments.
Branding Changes - Masterpage , CSS , site templates , images ,etc. While most of these changes can be and "should be" deployed through a visual studio solution for the sake of release tracking and version control, you can make certain exceptions when it comes to deployment images. css files for a internet facing website.
Under such scenarios, you can certainly replace the existing files in the 14 hive folder physically for all your web front end servers if your internet facing site calls for zero downtime.
In this case, you wont need an IIS Reset and users get to see the branding changes with a page/cache refresh in their browsers.
there are many factors, some that ill explain!
deploying a wsp (solution file) will cause a IISreset, reason being its changing things within the 12/14/15 hive, it could also be adding strongly named dlls to the gac (global assembly cache) and many other factors.
IISresets on live servers should NOT be performed during working hours (late evening or morning)! it should be run when no one is logged in. On test enviroments its down to you and the business ;), iv done it plenty of times when on test enviroment whilst others performing an action and it times out causing people to shout lol just make sure they know! on your own enviroment well that is up to you and you can do it as much as you want!
i know its easy to hit run and type in "iisreset" and then hit enter! that is fine but not on live! do this instead "iisreset /noforce" , let things in memory finish!
The /noforce parameter is recommended as a safeguard against data loss in case the IIS services cannot all be stopped within the one minute timeout period. If you are certain that it is safe to force IIS to restart, you can omit the /noforce parameter. In addition, if you are logged on locally, the computername parameter is not required. If you are administering an IIS server remotely, the computername parameter is the NetBIOS name of the computer on which you wish to restart IIS.
all about iisreset
http://technet.microsoft.com/en-us/library/cc758159(v=ws.10).aspx
on that note dont do it to all webapps when deploying a solution ;) do it to the one you added it to through a script unless its a global solution:
there is an exception to partial trusted apps that dlls reside within the bin folder, that does not nees an iisreset to work!
also running a wakeup script will help!
at points within businesses it does come down to making emergency changes that require you to add a solution that requires an iisreset and that is fine aslong as minimal users a signed in at that given point and also targeting a specific webapp!
more about iisreset:
as for anything else like page layouts and masterpage well no there is no need for an iisreset as the are normally stored within a sharepoint list and take effect straight away.
