Redirecting HTTP to HTTPS on IIS

It can be beneficial for security and SEO reasons to secure an entire website, rather than pages were there are login forms and other private data. The myths around performance hits have been debunked, and the main potential downside is around third-party ad networks (and many sites don't display ads like this anyway).

To achieve redirection from non-secure to secure URLs on an IIS website, the URL Rewrite Module will need to be installed on the server. Then the following XML will need to be added into the web.config (site root) inside the system.web server section.

<rewrite>

    <rules>

      <rule name="HTTP to HTTPS redirect" stopProcessing="true">

        <match url="(.*)" />

        <conditions>

          <add input="{HTTPS}" pattern="off" ignoreCase="true" />

        </conditions>

        <action type="Redirect" redirectType="Found" url="https://{HTTP_HOST}/{R:1}" />

      </rule>

    </rules>

</rewrite>

Sitecore Event Queue – How to clean it

STEP 1: CLEAN OUT EVENT QUEUE, HISTORY TABLE, PUBLISH QUEUE

The following SQL statement will clean out the history table, publish queue and event queue, leaving only 12 hours of history and publish data and 4 hours of events. Replace YOURDATABASE with the name of your database:

/****** History ******/

delete FROM [YOURDATABASE_Core].[dbo].[History] where Created < DATEADD(HOUR, -12, GETDATE())

delete FROM [YOURDATABASE_Master].[dbo].[History] where Created < DATEADD(HOUR, -12, GETDATE())

delete FROM [YOURDATABASE_Web].[dbo].[History] where Created < DATEADD(HOUR, -12, GETDATE())

  

/****** Publishqueue ******/

delete FROM [YOURDATABASE_Core].[dbo].[PublishQueue] where Date < DATEADD(HOUR, -12, GETDATE());    

delete FROM [YOURDATABASE_Master].[dbo].[PublishQueue] where Date < DATEADD(HOUR, -12, GETDATE());

delete FROM [YOURDATABASE_Web].[dbo].[PublishQueue] where Date < DATEADD(HOUR, -12, GETDATE());

     

/****** EventQueue ******/

delete FROM [YOURDATABASE_Master].[dbo].[EventQueue] where [Created] < DATEADD(HOUR, -4, GETDATE())

delete FROM [YOURDATABASE_Core].[dbo].[EventQueue] where [Created] < DATEADD(HOUR, -4, GETDATE())

delete FROM [YOURDATABASE_Web].[dbo].[EventQueue] where [Created] < DATEADD(HOUR, -4, GETDATE())

STEP 2: CONFIGURE THE SYSTEM TO CLEAN THE TABLES MORE OFTEN

With the system stabilized, we need to take more care of the table sizes.

HISTORY TABLE:

Sitecore is already configured to clean the tables so they only contain 12 hours of data. 

12 hours of data is usually what any SQL server will handle, and you will have up to 10.000 rows in the table.

<Engines.HistoryEngine.Storage>

  <obj type="Sitecore.Data.$(database).$(database)HistoryStorage, Sitecore.Kernel">

    <param connectionStringName="$(id)" />

    <EntryLifeTime>00.12:00:00</EntryLifeTime>

  </obj>

</Engines.HistoryEngine.Storage>

PUBLISH QUEUE:

Sitecore keeps 30 days of publishing queue. If you insert and update items often, you should lower this number. For each item change (including any change that the system does) is stored here.

<agent type="Sitecore.Tasks.CleanupPublishQueue, Sitecore.Kernel" method="Run" interval="04:00:00">

  <DaysToKeep>2</DaysToKeep>

</agent>

EVENT QUEUE:

The event queue is the most important table to keep small. In a distributed environment, each server will read the contents of the table every 5 seconds, using a time stamp stored in the If you can keep the number of rows below 7.000, most SQL server should be able to handle that amount of data. Even smaller numbers are preferred as well. Properties table as key. Any row before the timestamp will not be read.

You, therefore, need enough history to cater that a server will be offline for a while, but at the same time so little contents that any read and write will be amazingly fast.

Before Sitecore 8.1, Sitecore would only allow you to clean events older that 1 day. This is way too much, especially if you publish often. The new IntervalToKeep will allow you to determine the hours to keep as well:

<agent type="Sitecore.Tasks.CleanupEventQueue, Sitecore.Kernel" method="Run" interval="04:00:00">

  <IntervalToKeep>04:00:00</IntervalToKeep>

  <DaysToKeep>1</DaysToKeep>

</agent>

Adding publish item to the contextual menu of Sitecore

Publish Operations and Messages.

This picture shows how each menu item is related to the corresponding message.

Customizing the Context Menu.

Switch to the Core Database and go to the "/Sitecore/content/Applications/Content Editor/Context Menues/Default" folder and create a new Menu item  (Template Path : /Sitecore/templates/System/Menus/Menu item). You can re-order existing menu items to your liking. For your new menu item, choose a display name (in my case, its "Publish Menu"), an icon and finally the message (in my case, I've used item: publish(id=$Target)). See the below image.

Now, to avoid disappointments, in the scenario where a user may think that they can publish, to later found out they can’t, we have to apply security:

• A select item which is created right now (Ex: Publish menu)
• Click on Security navigation Bar.
• Click on the Assign inside security section and its open a popup.
• Add role "Sitecore client Publishing" and "Sitecore client Users".
• Click ok button.

All you now have to do is to switch back to the master base and view the result. Simple !!! :) You should get something like this:

IIS Restart Using Command Prompt

To restart IIS using the IISReset command-line utility

• From the Start menu, click Run.
• In the Open box, type cmd, and click OK.
• At the command prompt, type
  
  iisreset /noforce and press ENTER.
  
  
  
  
  
• IIS attempts to stop all services before restarting. The IISReset command-line utility waits up to one minute for all services to stop. If the services cannot be stopped within one minute, all IIS services are terminated, and IIS restarts.

Common Reasons why your application pool may unexpectedly recycle

If your application crashes, hangs and deadlocks it will cause/require the application pool to recycle in order to be resolved, but sometimes your application pool inexplicably recycles for no obvious reason. This is usually a configuration issue or due to the fact that you're performing file system operations in the application directory.


Editing and updating

ASP.NET depends on File Change Notifications (FCN) to see if the application has been updated. Depending on the change the application pool will recycle. If you or your application is adding and removing directories to the application folder, then you will be restarting your application pool every time, so be careful with those temporary files.

Altering the following files will also trigger an immediate restart of the application pool:

• web.config
• machine.config
• global.asax
• Anything in the bin directory or it's sub-directories

Updating the .aspx files, etc. causing a recompile will eventually trigger a restart of the application pool as well. There is a property of the compilation element under system.web that is called numRecompilesBeforeAppRestart. The default value is 20. This means that after 20 recompiles the application pool will recycle.

How to Recycle Application Pool Automatically In IIS ?

your website hosted server is consuming 95% CPU utilization due to IIS worker process and within a few minutes, your server is going to crash and your website will not be accessible?

Let's say if CPU utilization reached 92% and it remains at 92% or more for the next 3 minute then we want IIS should recycle application pool automatically.

Follow below steps to achieve this.

• Open IIS. 
• Right click on your website application pool and select “Advanced Settings…”
• Locate CPU section 
• Put Limit (percent) as 92% 
• Set Limit Action at KillW3wp 
• Set Limit Interval (minutes) at 3 
• Click Ok

Here is a screenshot for quick understanding

Now no manual intervention is required. But remember this is not a solution, this is just a workaround for the problem. You should find the root cause of the problem.