O
Owe Evans
The tied timesheet mode solution starter - which can be found on codeplex -
is of great benefit to customers since it leverage the obstacle of both
reporting time in timesheet and task updates.
However, I have found out myselft and also heard other having trouble
deploying the solution. The reason I posted this is that I wanted to share my
experience with deploying the solution and I feel the installation
documentation on CodePlex has some details missing that makes deploying on a
multi-tier system to be hard. S
First of all I want to point out that my experience with this is that it
works very well once you figured it out. But this has been a iterative
process during which I have had the opportunity to have the help of for
example Christophe. So I want to share with you my way on how to set this
solution up on a three tier solution - that is a Web Front end server, a app
server running Central Admin and of course the Database server.
From the beginning the solution did only encompass the Event handler. In
it's second edition it has been refined with an internal "queue" mechanism.
Today the solution is built up on three main part:
- the actual Timesheet event handler class - called timesheetevent.dll. This
is the mechanism that gets fired when a timesheet is saved and it creates a
"job order" in the autostatusing table.
- the database table and stored procedures working as a "queue"
- the NT service that polls the database for new jobs and if any found
processes the timesheet into a task update
So how to deploy / my experience on what might go wrong:
(Please not that this is how I got it working in my last deployment. Not a
single time I'd got it right from the beginning ;-)
- make sure you have the appropriate rights to create the database table and
stored procedures in database server
- the ProjectServer_Reporting database is the place where it should be
created.
- In my latest setup the farm consisted of a Web Front end server, a app
server running Central Admin and a database server.
- The msi (setup) was ran on the app server. (In an earlier installation
when trying to install on the web front end the statusing.asmx was not found
which depends on in which order you add the server to the farm.) So the
recommendation would be to install on the app server. No need to run the MSI
on the WFE.
- The only thing you need to be careful with when running the installation
is the "Set service credentials". The installation documentation does not
give you much on this. Actually - the easiest (most appropriate?) would be to
enter the SSP service account here. This account can be found if going to
Central Admin - click Shared Service link - click the drop down on the Shared
service top node and choose Edit or View - Shared Service Provider
Credentials.
- After running the MSI (with success) there might be some quirks to deal
with (and yes - not one time the MSI installation took care of them all ...)
-- Register the event handler in PWA - server settings. Sometimes no
registration at all has taken place after the installation. Other times the
Event Handler was registered but when saving a Timesheet the Save was
cancelled. If this happens you can see something like "timesheet event class
could not be loaded in the Application log on the app server. The remedy is
to delete the registered handler and re-register it. With the same settings!
-- Deploy the Event Handler assembly to Global Assembly Cache. I always need
to do this. Drag and drop timesheetevent.dll from installation folder to
c:\windows\assembly in another explorer windows.
-- Make adjustments in TSAutoStatusing.exe.config;
--- Set hostname to app server name (since this is where PSI web services
are).
--- Remove the time in the StartTime setting, i.e. blank out 19:00
--- Create the LOGS folder in installation path and give read / write
permissions to the SSP account
--- Add a key in RegEdit "EPM 2007 Timesheet Event" under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application
--- Set execute rights on the tsXXX stored procedures - grant to
ProjectServerRole
And finally ...
.... add the SSP service account as a user in PWA. I gave it Administrators
global rights and added it to Administrators group. If you don't add this
account as a user you will get "401 unauthorized" error. Actually the account
to add as a user is the account you set as "logon account" for the NT Service.
I hope you all will get it working!
Cheers,
Owe Evans
is of great benefit to customers since it leverage the obstacle of both
reporting time in timesheet and task updates.
However, I have found out myselft and also heard other having trouble
deploying the solution. The reason I posted this is that I wanted to share my
experience with deploying the solution and I feel the installation
documentation on CodePlex has some details missing that makes deploying on a
multi-tier system to be hard. S
First of all I want to point out that my experience with this is that it
works very well once you figured it out. But this has been a iterative
process during which I have had the opportunity to have the help of for
example Christophe. So I want to share with you my way on how to set this
solution up on a three tier solution - that is a Web Front end server, a app
server running Central Admin and of course the Database server.
From the beginning the solution did only encompass the Event handler. In
it's second edition it has been refined with an internal "queue" mechanism.
Today the solution is built up on three main part:
- the actual Timesheet event handler class - called timesheetevent.dll. This
is the mechanism that gets fired when a timesheet is saved and it creates a
"job order" in the autostatusing table.
- the database table and stored procedures working as a "queue"
- the NT service that polls the database for new jobs and if any found
processes the timesheet into a task update
So how to deploy / my experience on what might go wrong:
(Please not that this is how I got it working in my last deployment. Not a
single time I'd got it right from the beginning ;-)
- make sure you have the appropriate rights to create the database table and
stored procedures in database server
- the ProjectServer_Reporting database is the place where it should be
created.
- In my latest setup the farm consisted of a Web Front end server, a app
server running Central Admin and a database server.
- The msi (setup) was ran on the app server. (In an earlier installation
when trying to install on the web front end the statusing.asmx was not found
which depends on in which order you add the server to the farm.) So the
recommendation would be to install on the app server. No need to run the MSI
on the WFE.
- The only thing you need to be careful with when running the installation
is the "Set service credentials". The installation documentation does not
give you much on this. Actually - the easiest (most appropriate?) would be to
enter the SSP service account here. This account can be found if going to
Central Admin - click Shared Service link - click the drop down on the Shared
service top node and choose Edit or View - Shared Service Provider
Credentials.
- After running the MSI (with success) there might be some quirks to deal
with (and yes - not one time the MSI installation took care of them all ...)
-- Register the event handler in PWA - server settings. Sometimes no
registration at all has taken place after the installation. Other times the
Event Handler was registered but when saving a Timesheet the Save was
cancelled. If this happens you can see something like "timesheet event class
could not be loaded in the Application log on the app server. The remedy is
to delete the registered handler and re-register it. With the same settings!
-- Deploy the Event Handler assembly to Global Assembly Cache. I always need
to do this. Drag and drop timesheetevent.dll from installation folder to
c:\windows\assembly in another explorer windows.
-- Make adjustments in TSAutoStatusing.exe.config;
--- Set hostname to app server name (since this is where PSI web services
are).
--- Remove the time in the StartTime setting, i.e. blank out 19:00
--- Create the LOGS folder in installation path and give read / write
permissions to the SSP account
--- Add a key in RegEdit "EPM 2007 Timesheet Event" under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application
--- Set execute rights on the tsXXX stored procedures - grant to
ProjectServerRole
And finally ...
.... add the SSP service account as a user in PWA. I gave it Administrators
global rights and added it to Administrators group. If you don't add this
account as a user you will get "401 unauthorized" error. Actually the account
to add as a user is the account you set as "logon account" for the NT Service.
I hope you all will get it working!
Cheers,
Owe Evans