We're having an 'interesting' IIS deployment problem in one of TeamMentor live servers (running IIS 7.5)
After installing an TM library (using the technique show in the Installing New Libraries via control panel video) I was faced with this:
An instance of TM with the Library Structure OK, but with no content
A quick look at the debug page shows that the cache file failed to be created due to a permission problem:
Basically the current IIS worker account (from the Application Pool) is not able to write the /XmlDatabase/TM_Libraries folder.
One way to work around this (until the server is fixed), is to set a different TM Library path, which can be done on the control panel:
After that is set, we can reinstall the Library, in this case using a link to TM_Libraries_3.2.4.zip (password protected) which will trigger a server side download of that zip file (hosted at a GitGub download's page) , its unzip and server-side catche rebuild:
And after about 1 minute:
The TM site will be fully operational:
The question is: why did this worked?
Namely, why did the folder directly created via the web UI work and the previous one didn't?
The reason is that the original folder XmlDatabase/Tm_Libraries was created by MK (SI IT Admin) during the installation of this TM instance (using his account via RDP). And the XmlDatabase/Tm_Libraries_2 was created by IIS under the Application Pool identity (which have read/write privs to that folder, but not the one created by MK)
There are a couple twists here, specially because we are using IIS 7.5 which introduced a number of changes in the way the Application Pool accounts work (which I haven't had the time to fully look into it).
We are still trying to figure out the best workflow to set this up (with the objective to have a fully automated TM deployment set-up), so let me know if you have any good ideas or can share your experiences.
Note 1: Roman has posted a variation on this issue on his Permission Issue with IIS7.5 post, which btw, is also happening with this TM instance:
