Continuously Update Preview alert on SDL Tridion UI 2012 - tridion

Question

I am trying to establish new SDL Tridion UI 2012 functionality on some test (default) pages. I am continuously retrieve "The preview for this page is not up to date" alert despite the fact that I click on "Update preview" several time. I was using virtual image, so anyone else is not possible to edit page except myself. No matters which component changed. I have taken a look into cd_core.log file on "session preview" web service side and find these nodes interesting:
INFO WritableODataClaimProcessor - No session wrapper is installed, not allowing modification operations
DEBUG HandleSessionContentUtil - There are no session wrappers into storage config file!
DEBUG HandleSessionContentUtil - There are no session wrappers into storage config file!
DEBUG WebContext - setCurrentClaimStore: com.tridion.siteedit.preview.PreviewClaimStore#dc60af, thread: Thread-59
DEBUG WritableODataClaimProcessor - Removing sessionId claim from ClaimStore!
DEBUG ClaimStore - remove: uri=taf:claim:contentdelivery:webservice:preview:sessionid
DEBUG WebContext - setCurrentClaimStore: null, thread: Thread-59
The most interesting part is that session wrappers were added to cd_storage_conf.xml on "session preview" web service side. Bellow is part of "session preview" cd_storage_conf.xml:
<Storages>
<Wrappers>
<Wrapper Name="SessionWrapper">
<Timeout>120000</Timeout>
<Storage Type="persistence" Id="sqlServerDb" dialect="MSSQL" Class="com.tridion.storage.persistence.JPADAOFactory">
<Pool Type="jdbc" Size="5" MonitorInterval="60" IdleTimeout="120" CheckoutTimeout="120" />
<DataSource Class="com.microsoft.sqlserver.jdbc.SQLServerDataSource">
<Property Name="serverName" Value="T2011" />
<Property Name="portNumber" Value="1433" />
<Property Name="databaseName" Value="Tridion_Session_Preview"/>
<Property Name="user" Value="TridionSessionPreview"/>
<Property Name="password" Value="tridion"/>
</DataSource>
</Storage>
</Wrapper>
</Wrappers>
<StorageBindings>
<Bundle src="preview_dao_bundle.xml"/>
</StorageBindings>
<Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="staging" defaultFilesystem="false">
<Root Path="C:\inetpub\wwwroot\software" />
</Storage>
<Storage Type="persistence" Id="sqlServerDb" dialect="MSSQL" Class="com.tridion.storage.persistence.JPADAOFactory">
<Pool Type="jdbc" Size="5" MonitorInterval="60" IdleTimeout="120" CheckoutTimeout="120" />
<DataSource Class="com.microsoft.sqlserver.jdbc.SQLServerDataSource">
<Property Name="serverName" Value="T2011" />
<Property Name="portNumber" Value="1433" />
<Property Name="databaseName" Value="Tridion_Broker_Staging"/>
<Property Name="user" Value="TridionBrokerUser"/>
<Property Name="password" Value="tridion"/>
</DataSource>
</Storage>
</Storages>
</Global>
<ItemTypes defaultStorageId="sqlServerDb" cached="false">
<Item typeMapping="Page" cached="false" storageId="staging"/>
</ItemTypes>
I have check cd_storage_conf.xml validity state and everything is OK (try to open XML via IE and it is showed correctly).
When I republish the page (Finish Editing) everything is correct state after reload the page until the first change on any components is made. This unexpected state gave me such a strong pain and headache, furthermore create me a so nervous... :).

Answer 1

Here's what Update Preview does, make sure all the steps up to the actual page refresh work and are correctly configured and you should be good to do:
Render your template(s) in Preview Mode
Post the results to the Content Delivery Web Service
CD Web Service writes to Session Wrapper Database
Refresh the page
Ambient Framework filters (or HTTP Modules for .NET) check for a session token
DB is queried searching for content with the same session token
If content is found, it is merged with the content on the page.
Typical issues (in my experience so far) are around Ambient Framework Configuration - Either the modules are not installed/configured on your application, or the cd_ambient_conf.xml contains invalid configuration settings.
Might be worth tracing the logs from step 1 to figure out where it's failing - knowing where it fails is usually 80% of the solution.