How to manually generate your own Machine Key in IIS 7

The Machine Key module in IIS 7 can help you generate your own unique key for your ViewState. This method is helpful when your application pool is getting recycled.

1. Connect to the web server using IIS 7 Manager.
2. Go to the module “Machine Key”.
3. Click on “Generate Keys” on the left hand side of the IIS 7 Manager.
4. Click “Apply”.​

As you can see when you first go into the Machine Key module, the settings are SHA1 for the encryption method and Auto for the Decryption method. All check boxes (Automatically generate at runtime & Generate a unique key for each application) will have a check on it. When you click on the Generate Key attribute a hash string is generated for you and the “Automatically generate at runtime” option is unchecked. Everything else can be left to its default state.

This is the element created in your applications web.config file when you run through these steps.

Code:

<configuration>
    <system.web>
        <trust level="Full" />
        <machineKey decryption="AES" decryptionKey="C03B1AB0BC1ACCD18EA915CBD87373010AD0DEC430A69871,IsolateApps" validation="AES" validationKey="C0ED7C430148AD4BC6505085DA4FD0DD3EE2453B566FC4EA4C7B3C2DCAB2025A79C774370CA884DF909CE9A3D379E544B7890D0A1CEE164141D3A966999DC625,IsolateApps" />
    </system.web>
</configuration>

Normally I would tell you that you do not need to use IIS 7 Manager to input these attributes in your applications web.config file, but the hash string normally cannot be created without some kind of tool. There are some tools out on the Internet that can help you generate a SHA1 hash string but since IIS 7 already has that tool built in for you, this is something best done within IIS 7 itself.

If you are using ViewState and you find that your application pool is being recycled these steps should help you out. Now, bear in mind that sessions are a different problem all together and you may want to consider moving your session objects out of the web server and unto a SQL server.

http://support.Winhost.com/KB/a626/how-to-enable-aspnet-sql-server-session-on-your-web.aspx

 

After reading your post, it pretty much described the issues I am having with my site. I run a shopping cart program and rely heavily on sessions. For whatever reason the sessions will get dropped calling for the customer to login again or have their cart emptied.

Now I have set up a unique machine key to the application as mentioned in the first section. The second section required moving session objects out of the web server and onto a SQL server. I followed all the instructions provided from your link and had Winhost create a Session State database schema and was notified this was setup or activated.

Prior to requesting this I had already created a MS SQL database called essessions and through SQL Server MS I can access the database and view two tables, called ASPStateTempApplications and ASPStateTempSessions. Neither of these tables are being populated with data and I still experience the dropped sessions. When I go into IIS7 under State Server this is what I have:



The data string is as follows:
data Source=s04.Winhost.com;database=DB_6966_xxxxxx;user id=DB_6966_essessions_xxxxxx;password=xxxxxx

Maybe I am not understanding everything there is to do but if someone can shed some light on what I should expect from the State Server and possibly why the tables are not being populated I would appreciate it. I have to assume if the sessions are not being stored in the database then I have missed something.

Thanks.
Rick

 

Check your applications web.config file and make sure you manually define the session element in your applications web.config file.

Try looking at this link.

http://msdn.microsoft.com/en-us/library/h6bb9cz9(v=vs.71).aspx

 

Hi Ray, thanks for the information. Checking the web.config file it appears everything is defined. I changed a couple of settings to try and match what the link showed but I do not think it's working. The tables that were created (ASPStateTempSessions, ASPStateTempApplications) are still empty. I've attached the sessionState info from the web.config file. This is from the application directory.

<sessionState allowCustomSqlDatabase="false" cookieless="false" cookieName="xxxxxx" mode="SQLServer" sqlConnectionString="Data Source=tcp:s04.Winhost.com;Initial Catalog=DB_6966_xxxxxx;User ID=DB_6966_essessions_xxxxxx;Password=xxxxxx; Integrated Security=False" timeout="20" />

The above lines are embedded within system.web tags.

Do you see anything unusual with this? Any other info you can help with is appreciated.
Thanks.

 

I'll need a URL from you and some way to test it out. Try emailing me the details and hopefully a test account to use. Use my forum account to email the info to me.

 

Hi guys,

Any light on this? I have exactly the same problem. I had session state tables set up by the Support Dept. But strangely, no matter what I try, the session tables are always empty and session gets dropped very very frequently, even I'm actively navigating the site

I will try the custom machine key later, may be another update by then.

Cheers,
Hugh.

 

Hi there,
if you are using Classic ASP then apparently the session state does not work. Unfortuneately they were not able to resolve my issue with sessions being dropped.
Hope that helps on why the tables do not get populated.

 

Thanks for the response.
My web app is not a Classic ASP one but kinda silly because it can gets auto-recycled when it reaches the mark of 100MB allocated memory.
I personally don't like the ideal of 100MB allocated pool per app, it limits our ability and to upgrade to 200MB, you will need to pay $9.95/month. Then Winhost is not as good as an option any more. On top of that, 200MB is not the final answer. It might not be enough in several months time.

 

Well, unfortunately, if you run applications that require a lot of memory, you're going to pay more for hosting. That doesn't apply only to us, it applies everywhere.

You can still find shared hosts that don't isolate or limit your application pool if that's what you really want. They are becoming less common, but they are out there.

But remember - when they don't limit your resource use, they also don't limit the resource use of the other thousand (or more) sites that you share a server with. See any potential for trouble there?

The only way to manage a shared server and maintain usability for everyone is to limit resources for everyone.