Components and Tools
• Office 365
• SharePoint hosted
• Auto hosted
• Provider hosted
• SharePoint Hosted
• Provider Hosted
• Full Trust
A Release Distribution Process is actually nothing more than a
governance that you adopt depending your business needs and IT
deploys can be
done at 1PM
( lunch )
Impacted by a
problem and a
CU resolves it.
We install it in the
According to Microsoft: There are a few methods available to
minimize the amount of downtime; however it’s just not possible to
achieve a zero downtime solution for your upgrade.A common
way to minimize downtime is via implementation of a parallel
Use the Force switch only for fixing broken deployments of
SharePoint Packages. Not only it makes SharePoint stop affected
Application Pools but also it prevents you from seeing errors
should there be any.
There is a recycle on the Application Pool, Why don’t you do this at
04:00AM. 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.
When a solution is deployed globally, all SharePoint application
pools, including CentralAdministration’s, are recycled automatically.
This can be good and bad. This is good because any GAC installed
DLL that has been upgraded needs to be reloaded. This can be bad
though with regards to the availability of your entire SharePoint
Set the ResetWebServerModeOnUpgrade attribute to Recycle.
You have to do this explicitly in the SharePoint Package
configuration. Without it, the setting will default to the StartStop.
Who wrote my solution?Anybody who I can fully trust? Does he
write great code? Does he an IISReset in his code?
Do not create a WSP for layout Pages, CSS. Try to minimize the
amount of solutions. ‘Aspx’ files, DLL and controls are going to the
application domain and these files have to be compiled. Layouts,
CSS, resources not!
Schedule retracting of SharePoint Packages when there is the
least traffic on your Web Applications as it always stops affected
On many TechNet articles you can see that per Application Pool
you need 2GB of RAM.
A simple calculus could be for 40 Application Pools => 80GB or
RAM. This is not true!
Try to respect the 12 Application Pools per server and be generous
with the RAM (depending your hardware).
Many websites can be hosted on one Application Pool, but Many
Application Pools cannot be used by a Web Application. So the
question can be how can I manage my Web Applications while
keeping in mind the 12 Web Application Pools Limit? Well, all the
Application Pools should be together by usage or anything else
and divided by authentication model (claims, anonymous …)
Avoid creating a lot of global SharePoint Packages and try instead
to provision as much as you can to specific Web Applications.
Every time you touch a global SharePoint Package all Applications
Pools will be stopped/recycled.
application will never stopped or recycle
application pools and then start then one by one
SharePointwill first stop all the application pool and then start then one by one
SharePointwill first stop all the
application pool and then start then one by one
SharePointwill recycle the
applicationat the end of the progress
SharePointwill not recycle the application pool any more
avoid the unnecessary restarton the
stops all the application pool and start them again
will recycle them ratherthan stop and
application pool with no recycle.