Deployment Questions and Issues

Coordinator
Jan 16, 2008 at 4:09 PM
Post all your deployement questions and issues
Jan 21, 2008 at 2:41 AM
Hello,

I did try to install the application on a test environment. We are using Project server with SP1. I did followed the guide - below are the steps I did for your reference.

For testing. I tried to create a new timesheet, entered total of 40 hours for the week, Save the timesheet. The screen refreshes and all entered hours were gone. I did try to enter the hours again but this time clicked on Save and Submit, the usual comment box appeared , the screen refreshes and again all the entered hours were gone. If I enter the hours again and clicked on the Recalculate button, the no of hours are retained.

I then checked the tsautostatus table, and the table is empty. Since I'm a team member and also the project manager, task updates are also empty. - meaning no updates were sent to the pm.

Please help me. I really want to make this work. Thanks.


------------------
Step by Step installation MOSS04 of Timesheet Pseudo Tied Mode Service
1. Refer to EPMTimesheetAutoStatus_Service.doc for documentation.
2. Install Setup.MSI - parameters entered: database server: moss04. database name = PWA_Reporting. PWA URL: http://moss04/pwa. SSP value = DefaultSSP.
3. error during installation. "UpdateEventsConfig failed. Could not find a part of the path 'C:\program files\Microsoft Office Server\12.0\Bin|Microsoft.Office.Project.Server.Eventing.exe.config'."-Clicked on OK button, another prompt appear - set service login window, used <service accouunt used for MOSS and project server>. Installation completed.
4. edit .config file located at C:\Program Files\Microsoft\Timesheet Auto Approval Service
5. Created "logs" folder on C:\Program Files\Microsoft\Timesheet Auto Approval Service, and add write permission to <service account> account.
6. Start service: Microsoft Office Project Server Timesheet Auto Approval Service. Service successfully started.
Coordinator
Jan 22, 2008 at 5:30 PM
Do you still have the issue if the solution starter is uninstalled and removed?
Jan 28, 2008 at 2:32 AM
Hi Chris,

Sorry for the late reply. I have to double check the results before getting back to you. If I totally remove the service , the entered hours on timesheet remains upon clicking on save. If I uninstall it and reinstall it again - same issue - entered hours were gone upon clicking on save.

Please help. Thanks.

Jof
Coordinator
Jan 28, 2008 at 4:15 PM
Jof,
What does the customization logs says?
Jan 29, 2008 at 12:42 AM
Hi Chris,

The logs folder defined during the setup (if that's what you mean) is empty. Or do you mean ULS log?

JoF
Feb 6, 2008 at 2:11 AM
Hi Guys, I badly needed your help on this- I hope you can help me out -
Coordinator
Feb 6, 2008 at 2:30 AM
Jof,
Install Visual Studio and start debuging to ensure the event is properly firing.
Feb 6, 2008 at 4:09 PM
Edited Feb 6, 2008 at 4:12 PM
Chris,

I've got a 2 WFE, 2 App Server farm configuration with Windows SharePoint Services 3.0 SP1 & Office SharePoint Server 2007 SP1 installed. I ran the MSI on both App Servers. The install for app server 1, indicated that it was successful. Install for App Server 2 threw the following message: LastError=ServerEventHandlerDuplicateEntry. I clicked OK and the setup continued, prompting me for the account service credentials. Setup on app server 2 then indicated that install was successful. I then started the service on both app servers. I then saved a Timesheet with changes to actuals and went to check My Tasks. There were no changes to the Progress of the tasks I saved hours for. The database table was there but empty. I went to check the Timesheet Auto Approval Service logs but the (default installation path)\Logs folder is not on either server. Checked the ULS log and found the following: Microsoft.Office.Project.Server (0x081C) 0x0804 Project Server Project Server Server-Side Even 6662 Critical EventHandler: "TimesheetEvent, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1c3c442d16e0416b, Microsoft.EPM.Events.TimesheetEvent.TSOnUpdated" could not be loaded
Tried to find TimesheetEvent in the GAC and could not find it on either server.
I then un-installed the service from both app servers which indicated successful. Double checked the uninstall and found that both PWA Timesheet Server-Side Event Handlers, Updating and Submitting were still there so I deleted them. Waited till they were deleted. Tried to re-install the Setup.msi on app server 1 and get the LastError=ServerEventHandlerDuplicateEntry even though there aren’t any PWA Timesheet Server-Side Event Handlers registered (I double checked). Any suggestions to get bits installed on these app servers?

Thanks
Coordinator
Feb 6, 2008 at 6:55 PM
I recommend you deploy it manually (the dll, the config and the event configuration) using the procedure described in this document:
https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=EPMTSST&ReleaseId=8430
Feb 8, 2008 at 11:48 PM
Edited Feb 8, 2008 at 11:49 PM
Chris,
Thank you, I was able to get the starter app installed on both app servers. Now I’ve got another issue. The following is logged in the Event log of WFE.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Project Server Timesheet
Event ID: 7851
Date: 2/8/2008
Time: 5:18:25 PM
User: N/A
Computer: <WFE_NAME>
Description:
Standard Information:PSI Entry Point: Statusing.ImportTimesheet
Project User: <Logged on User account>
Correlation Id: 5c996859-fa4b-4727-bb32-2adfd9df94d5
PWA Site URL: http://<WFE_NAME>/PWA
SSP Name: PWA
PSError: TimesheetIncorrectPeriod (3208)
Timesheet period used '(null)' is invalid.

Upon further investigation, I find that the ImportTimesheetDataSet returned from this call contains no Lines. StatusingWS.ImportTimesheetDataSet importTimeSheetDs = statusingWS.ReadImportTimesheetData(periodUid);

No exceptions are thrown.
The periodUid is valid and I saved changes to the TimesheetDataset. Do you have any thoughts as to why the importTimeSheetDs would be returned empty?

Thanks,
Coordinator
Feb 9, 2008 at 2:28 AM
This time or error typically has to do with an incorrect Impersonation, basically the wrong user ID is being used when the importTS method is called.
Are you using HTTPS, Forms Auth?
Feb 9, 2008 at 5:53 PM
I wrote a test page with a hardcoded periodUid for the statusingWS.ReadImportTimesheetData(periodUid) method. I am the logged on User trying to import my timesheet. Impersonation is not the issue with regards to my test page, My test page was an effort to evaluate what might be going wrong with the AutoStatus bits. The farm is using NTLM. No HTTPS or Forms Authentication.

Thanks,
Coordinator
Feb 11, 2008 at 5:08 AM
Trust me, impersonation is the issue. You need to do a stepo by step debug and ensure the user ID is the correct one when you call the statusing web service
Feb 21, 2008 at 1:46 AM
Chris,
The problem with the statusingWS.ReadImportTimesheetData(periodUid) recordset being empty was because the Timesheet Lines that I was attempting to import did not have the “Standard Line Classification” line class assigned: (TSLINECLASS_UID=’fcdb0e4e-b9c7-4a39-804f-fa44796f71a0’) . Microsoft will let you create all the custom timesheet line classifications you want, but fail to inform you that time logged against one of your custom line classifications will not be imported.

There was a case opened Feb 14, 2007 (that’s right, 2007) and was closed as “By Design”. I just happened to be on the phone with the Project Server Product Support Team almost one year to the day that the original case was opened. After a very long day on the phone with them, the case escalated to the point that Brian Smith got on the phone and set me straight. Read Brian’s blog on this topic http://blogs.msdn.com/brismith/archive/2008/02/15/timesheet-classifications-what-they-don-t-do.aspx
which was posted in the hopes to get the word out to the community and avoid any further confusion.

Once I got the data reconciled and got the PSLibrary.TimesheetConst.const_StandardLineClassGuid assigned to the appropriate TimesheetDataSet.Lines, the TSAutoStatus bits works great! Hats off to all who contributed to this work


PSLibrary.TimesheetConst.const_StandardLineClassGuid = ’fcdb0e4e-b9c7-4a39-804f-fa44796f71a0’

Thanks
Feb 29, 2008 at 4:38 PM
Hello,

I tried several times to deploy the TiedModeService using the .msi and the TimesheetEvent.dll is never deploy in the GAC.
You have to register it manually.
Mar 19, 2008 at 9:36 AM
I realise this is a stupid question; but has anyone got either of these components installed and working correctly?

EPMTSST
Couldn't GAC the dll - kept getting error.
Installed Visual Studio; it installed on build. Fine.
Setup the Event Handler.
Tried to trigger. Nothing. No log files. No success.
Even line being entered in timesheet was disappearing.

AUTOSTATSSERVICE
"Installation Successful"
dll not installed during installation - so what do you do? The auto triggers have different PublicKeyTokens from the EPMTSST; so followed advice above and manually installed; no good. Changed the PublicKeyToken to match. No good.
Line disappearing in timesheet again?!!??!?

Please - any advice?
Apr 24, 2008 at 11:38 PM
I have just recently attended to Christophe Fiessinger's great webcast on Timesheet customization. And having heard my boss coming into the office last week chanting "I've found a customer that does not want to use the "TiedMode Timesheet solution" I recon this is something many customers is wanting and I thought I would share my experience on deploying this.

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. So when I just have learned that one - there was a new solution on CodePlex.

The reason I posted this is that I feel the installation documentation on CodePlex has some details missing that makes deploying on a multi-tier system to be hard.

Today the deployment 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 HKEYLOCALMACHINE\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.

I hope you all will get it working!

Cheers,
Owe Evans
May 13, 2008 at 6:59 AM

Hi Christophe (and others),

I've tried to install this a few times in my environment and keep coming up against 2 problems;
a. The TimesheetEvent.dll does not seem to get registered in the GAC - I've had to drag this in manually
b. When I save the Timesheet, the actual hours disappear

Using the setup.msi program, I get the following error;

Event Handler Registration Failed.
System.Web.Services.Protocols.SoapException: ProjectServerError(s) LastError = ServerEventHandlerDuplicateEntry
Instructions: Pass this into the PSClientError constructor to access all error information
 at Microsoft.Office.Project.Server.Webservice.Events.CreateEventHandlerAssociations(EventHandlersDataSet
eventHandlers)

When I re-run setup.msi and choose "Repair" I get;

Event Handler Registration Failed.
Invalide URI : The format of the URI could not be determined.

If I check the Server Side Events through PWA > Server Settings, I can see it there under Timesheet > Updated.

When I save my timesheet, the actual hours disappear. In the Application Log, I get the following error;

TimesheetEvent, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1c3c442d16e0416b, Microsoft.EPM.Events.TimesheetEvent.TSOnUpdated
Could not load file or assembly 'TimesheetEvent, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1c3c442d16e0416b' or one of its dependencies. The system cannot find the file specified.

I'm no programmer (i.e. don't know how to use Visual Studio). How can I fix this?? Any help most appreciated.

Cheers,

Andy

May 13, 2008 at 10:21 AM
Hi Andy,

Setup.msi seems to never be able to install timesheetevent.dll in GAC - you have to do this manually.

It should not be necessary for you to use Visual Studio.

Check that the public key token entered in eventhandler registration is OK against the actual value the dll is having in GAC. (Right click - properties)

If it is ok, I would suggest you re-register the eventhandler manually.

Is this a single server installation or multi-tier?

Cheers,
Owe
May 13, 2008 at 10:48 AM

Hi Owe,

Thanks for your help!

I'll check the public key toke on the eventhandler to see if that helps. If I need to re-register, do I do that by editing the public key token in PWA > Server Settings > Server Side Event Handler Config?

The system is multi tier; DB server, MOSS server running Central Admin/SSP, Project Server.

Cheers,

Andy

May 13, 2008 at 2:24 PM
Hi Andy,
If the public key token is invalid - just alter it (in Server Side Event Handler Config)

If the public key token is OK from the beginning you might need to re-register the event handler (in Server Side Event Handler Config)
. That is, first delete it and then add it again. (I think the registration fails in the first time because the timesheetevent.dll do not get installed in GAC)

/Owe
Coordinator
May 13, 2008 at 2:59 PM
Use this tool to deploy and register event handlers: http://www.codeplex.com/PS2007EventHandler
May 14, 2008 at 5:15 PM

Hi Guys,

First of all, thanks to Christophe for building this sample solution. Every single one of my clients has requested the timesheet / task tied mode; separating the timesheet to such an extent is definitely the “exception” and not the “rule” in real world implementations. Microsoft should listen more to their clients, perhaps they would make better products if they did. This issue has pushed back 2007 adoption.

We have tested Christophe’s solution and it works well; although we have yet to see how it will scale. As others have indicated, there are problems with the installer and the documentation; I thought I would share some of my notes:

1. Timesheet.dll needs to be loaded to the GAC of each Application Server; do this manually

2. Timer (Timesheet Auto Approval) service should be installed on all App Servers for cold failover; however, it should only be running on only one. Disable on all others.

3. Use SSP service credentials for Timer (Timesheet Auto Approval service); SSP service credentials also require access to the “log” folder. It must be the SSP where Project Server is installed.

4. The default config file (TSAutoStatusing.config) schedules StartTime at 19:00, remove the value so that it runs constantly otherwise you will have some time to wait for the Task Changes to be submitted.

5. Custom Event Handler must be registered in the following, check and reregister manually as required:

                Timesheet – Line Approving

                Timesheet – Updating

                Timesheet – Updated

                Timesheet – Submitting

6. Although obvious, PWASSPName is the “name” of the SSP not the “URL”.

 

Barry

 

PS: Does anyone have the link to Christophe’s webcast? I would really like to see it.

Coordinator
May 16, 2008 at 3:20 AM

THANK YOU ALL for the great feedback.

I have just fixed the installer to add the DLL to the GAC and I have updated the documentation with your "field" feedback, current release is now v1.5

May 18, 2008 at 10:56 AM

Hi All,

Got it working! Thanks to Christophe, Owe and Barry for their help. Essentially, Barry's instructions were correct, however I had a few more steps to undertake. Here's what I did;

1.     Download and extract the solution from http://www.codeplex.com/AutoStatusService

2.     Run “SetUp.msi” and follow the prompts.
3.     This msi will install to “C:\Program Files\Microsoft\Timesheet Auto Approval Service\”

4.     Once the installation is complete, manually create a directory called “Logs” under the installation directory. The application will place log files in this directory which will assist with any debugging that will be required.

5.     Copy “TimesheetEvent.dll” to the GAC (“C:\Windows\Assembly”).

6.     Update the configuration file “TSAutoStatus.exe.config”
7.     Restart the “Microsoft Office Project Server Events” Service.
8.     Start the “Microsoft Office Project Server Timesheet Auto Approval” Service.
9.     After receiving the following error within the Event Log, the PSI Event Admin Tool (http://www.codeplex.com/PS2007EventHandler) was installed.

EventHandler: \TimesheetEvent, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1c3c442d16e0416b, Microsoft.EPM.Events.TimesheetEvent.TSOnUpdated\ could not be loaded

 

10.  The existing Server Side events were removed using the PSI Event Admin tool and re-added after browsing to C:\Windows\Assembly\TimesheetEvent.dll and adding the handlers

11.  After receiving the following errors in the event log, execute permissions were granted to the “Public” role within the Project Server reporting database;

 

EXECUTE permission denied on object 'tsAddTimesheet', database 'ProjectServer_Reporting', schema 'dbo'.

Error in QueueApproval

 

12.  The solution was now successfully installed!

 

 



Thanks everyone. It's an interesting solution, to be sure; took a little while to work through all the various scenarios to understand it (i.e. what happens if there is a 2 stage Timesheet approval process and the Task Update gets rejected), etc.

Cheers,

Andy

Jun 9, 2008 at 11:10 AM
14:08:52: STEP 1 - Initialize Web Service urls
14:08:52: STEP 2 - Start event override for timesheet UID: ad945c50-4aae-4d49-bd5a-66342563ef79
14:08:52: STEP 3 - Statusing Impersonation for RES_UID: cf91e231-8a1e-49a0-834c-eb57bda934fa
14:08:53: FAILED due to an exception: The request failed with HTTP status 404: Not Found.
14:08:53: SubmitStatus: True; timesheet URL: http://st-it/PWA/_vti_bin/psi/timesheet.asmx; statusing URL: http://st-it:56737/SharedServices/psi/statusing.asmx
14:08:53: Timesheet: Мое расписание; Resource: ST_Resource_1; Creator: ST_Resource_1, Period: c9107b82-3c9d-4729-9190-9b4daa1583b5
14:08:53: Total execution time: 1,48 seconds; SubmitStatus: 0,00 seconds


I have this error. Who know the reason?
Coordinator
Jun 9, 2008 at 11:18 PM
An IIS 404 typically means it's the wrong URL, are these two correct?

Jul 16, 2008 at 3:31 AM

In case it helps someone else:
I ran into an issue that hadn't been mentioned before. I was getting an error from the Event Service that it could not connect to the database. The Event log was pretty clear that it could not connect to the SQL server. I spent way too long looking at the TSAutoStatus.exe.config file and double, triple, &c checking that my settings were correct.

Duh. Wrong file. It turns out that the settings weren't written to the Microsoft.Office.Project.Server.Eventing.exe.config file. I had to manually edit that with the SQL server name and reporting DB. The Project Server event handlers get their config from there. 

Restart the Microsoft Office Project Server Event Service, and then I was in business.

(BTW, the name of the config file is not right in some of the docs. Should be TSAutoStatus.exe.config but is TSAutoStatusing.config in a few places.)


jf

Jul 30, 2008 at 1:50 PM

Hello,

I get the following error message when I run the setup: "Error running database scripts, Line 15: incorrect syntax near'('.

Database is installed on a different server. Necessary rights have been granted to the Reporting database.

Any idea?

Kind regards

Rolf

 

 

Aug 28, 2008 at 5:29 PM
Hi,

Any reponse/resolution to this error "error running database scripts, Line 15....."?   I am having a similar issue where the msi install failed to create the database table/stored proc., with a separate physical SQL 2000 box.  The msi gave me a credential error, although I have ran it several times after confirming the account used had the right access.  It looks to be passing the server the SQL server name instead of the domain user account.  So, I tried to take the install SQL query file and simply run that manually on the SQL server, but I run into the "line 15" error.

Thanks for any replies and also for the great resources here!

Regards, Paul
Aug 29, 2008 at 1:51 PM
Just a follow-up that I figured out the line 15 error was being caused by using an outdated version of SQL server (2000) and the syntax in the create objects script had to be tweaked a little to get it to run on 2000.  I was able to get that to run through successfully, but now I get a connection error in the event log when I start the timesheet service.  Although I'm not a coder/SQL guy, I'm guessing that the calls the project server is making to the SQL server for the timesheet service are expecting a SQL 2005 backend too.  I haven't got that part figured out yet (besides the obvious upgrade to SQL 2005), so I'll follow-up if I find something more......thanks!
Sep 18, 2008 at 5:55 AM
Edited Sep 18, 2008 at 6:47 AM
Simon,

I also have the same problem. Like you, I had numerous issues with the .MSI installation, though I handled the SQL script execution a little differently. I proceeded to open up anonymous authentication to the Reporting database just for the time it took to run the installation, which moved me along.

I remember seeing another three or so errors (it doesn't seem very robust), but the main one I remember alluded to the Microsoft.Office.Project.Server.Eventing.exe.config not being in the "right" location (a C:\Program Files reference, when the application is in fact installed on D:\Program Files), but now I'm also as the same stage you are, where I recieve the following error in the Application event log each time a user updates a timesheet:

Source:  EPM 2007 Timesheet Event
Category:  None
Event ID:  8989

Description:
Connection string is null.

For someone like me, that's being forced into the EPMS area quite quickly, I simply don't have the understanding required to take such a general description and turn it into some kind of actionable resolution. Like you, if I fluke my way through this, I'll post back here with the details.

Just a quick edit to note that we're running SQL Server 2005, so the version difference alone won't be your issue.

Cheers,
Lain
Sep 19, 2008 at 9:16 AM
Edited Sep 19, 2008 at 9:26 AM
As a follow-up to my own problem - and Simon's, I managed to resolve the "Connection string is null" error (from the Application event log).

Quick recap on the environment:
  • Sharepoint Services 3.0 w/SP1 installed on the front-end server;
  • Project Server 2007 w/SP1 installed on the front-end server;
  • SQL Server 2005 w/SP2 and Cumulative Rollup 7 Database Services (two instances - one for production; one for test) only on the first database server;
  • SQL Server 2005 w/SP2 and Cumulative Rollup 7 Analysis Services and Reporting Services (two instances of each, as above) only on the second database server.

So all up, there are three servers in the distributed solution.

Getting back to the problem with installing the Timesheet application, I had numerous errors with the MSI installer - not all of which I remember. I'm only going to cover the two that really seemed to matter:

  1. Unable to process the SQL Server script:
    1. Cancel out of the MSI installer;
    2. Use SQL Server Management Studio to connect to the server hosting your reporting database;
    3. In the Security\Logins section for the server, add the NT AUTHORITY\ANONYMOUS LOGON Windows user;
    4. Grant this user dbo rights (for convenience) to your reporting database;
    5. Re-run the MSI installer for the Timesheet application, and you should now find that it's able to process the SQL script portion of the installation;
    6. In the Security\Logins section for the server, edit the properties of the user and remove it's rights to the Reporting database!
    7. I'd also recommend you either disable this login as a minimum, or even remove it from the server now that it's purpose has been served.
  2. The installation completes successfully, but you find the following details in your server's Application log (on the Project Server front end - where the MSI is being installed):

    Source:  EPM 2007 Timesheet Event
    Category:  None
    Event ID:  8989

    Description:
    Connection string is null.


    1. Find your Windows Sharepoint Services installtion directory;
    2. Open the following file in Notepad:  \12.0\Bin\Microsoft.Office.Project.Server.Eventing.exe.config;
    3. Find the <appSettings> tag and add the following two lines after the opening tag (See below for a more complete example):
      1. <add key="DBServer" value="your_DatabaseServerName_Here" />
      2. <add key="DBName" value="your_ReportingDatabaseName_Here" />
    4. Save and close the file;
    5. Stop the "Microsoft Office Project Server Timesheet Auto Approval Service" service;
    6. Stop then restart the "Microsoft Office Project Server Events Service" service;
    7. Start the "Microsoft Office Project Server Timesheet Auto Approval Service" service;
    8. Within the PWA application, edit a timesheet and change some hours around;
    9. Choose the Save option;
    10. Check the Application log, and you should find you now see information events with the following details (which indicates the timesheet event is now working as expected):

      Source:  EPM 2007 Timesheet Event
      Category:  None
      Event ID:  8989

      Description:
      Update status on row 48

Below is a more complete example of the above mentioned \12.0\Bin\Microsoft.Office.Project.Server.Eventing.exe.config file - including the two additional lines.

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="ProjectServerEventHandlers"/>
      </assemblyBinding>
   </runtime>
   <appSettings>
      <add key="LogTimesheetEvent" value="True" />
      <add key="LogFileEveryHour" value="True" />
      <add key="LogFolderPath" value="D:\Logs\" />  
      <add key="PWASSPName" value="ProjectServerSSP" />        
      <add key="AutomaticallySubmitStatusUpdate" value="True" /> 
      <add key="DBServer" value="epms-srv1" />
      <add key="DBName" value="ProjectServer_Reporting" />
   </appSettings>     
</configuration>

Also worth mentioning is the fact we use domain accounts for the service logon credentials. We've had numerous issues with the server migration and the use of local accounts, so I'd highly recommend that you do NOT do as our company had done previously: be sure to only use domain accounts!


Hopefully this might assist some of the folks out there that have non-standard, distributed installations.

Cheers,
Lain
Sep 22, 2008 at 9:44 PM
I think I have encountered every error above...  Got a nice revised Install Doc out of it that I will post once I can confirm that this works.  The last (latest) error I cannot resolve seems to have been addressed earlier:

Standard Information:PSI Entry Point: Statusing.ImportTimesheet
...
PSError: TimesheetIncorrectPeriod (3208)
Timesheet period used '(null)' is invalid.

Following the earlier thread, how do I get the PSLibrary.TimesheetConst.const_StandardLineClassGuid assigned to the appropriate TimesheetDataSet.Lines?

I get the impression that this is a SQL setting, but I really dont know.

Thanks
lastashes
Sep 23, 2008 at 5:37 PM

Nevermind the above message, I got it working. 

Below is a compiled DRAFT of the installation instructions... it should get anyone through this install.

1.     Download and extract the solution from http://www.codeplex.com/AutoStatusService
2.     On the SQL Server, go to the Security/Logins section.  Open the properties section of the User representing the Application Server the PWA is located on.  Map the user to the Reporting Database for the PWA with a 'dbo' schema.  Next, go to the Reporting Database for the PWA.  Add the Application server as a user with full/every permissions.
3.     Run “SetUp.msi” and follow the prompts.
4.     This msi will install to “C:\Program Files\Microsoft\Timesheet Auto Approval Service\”

__________________________________________________________

Timesheet Auto Approval Service Setup

a.  Title page.  Click next
b.  Information Page.  Click next
c.  Settings Page. 
 provide Database Server name
 provide Reporting Database name
 provide Project Server URL
 provide Shared Service Provider name
 Click next
d.  Installation Page.  Select the appropriate settings for your organization.
 Click next
e.  Confirmation Page.  Click next
f.  Known Errors Pop-up. 
g.  Service Login.
 Enter <domain>\Username & Password combination

__________________________________________________________

5.     Once the installation is complete, manually create a directory called “Logs” under the installation directory. The application will place log files in this directory which will assist with any debugging that will be required.

6.     Copy “TimesheetEvent.dll” to the GAC (“C:\Windows\Assembly”).  The best method is to drag-and-drop the .dll into C:\Windows\Assembly.  Once the file has been transferred, right-click on the .dll and copy the Public Key Token to the clipboard.

_____________________________________________________________________________

1.  Register the assembly as safe in the web.config file that is associated with the Web site. There are typically several Web sites on a server. To find the correct web.config file, do the following:

(a) In the Microsoft Internet Information Services (IIS) Manager, expand the Web Sites node, right-click the Web site you will use, and click Properties. In many cases, Project Web Access is in the Default Web Site.

(b) In the Web Site Properties dialog box, click the Home Directory tab. You need to modify the web.config file in the directory specified in the Local path box.

(c) For example, if Local path is C:\Inetpub\Sample, use Notepad or any text editor to open the file C:\Inetpub\Sample\web.config.

2.  Create the following child element on one line within the SafeControls element.

Xml Copy Code:
<SafeControl Assembly="TimesheetEvent, Version=1.0.0.0, Culture=neutral, PublicKeyToken=[token]" Namespace="TimesheetEvent" TypeName="*" Safe="True" />

3.  Replace [token] with the public key token value. The SafeControl element and attributes must all be on one line. If there are any newline characters or other variations in the line, you get the error message previously described when you try to import the Web Part.

4.  Restart IIS. In a Command Prompt window, type iisreset.

##################################################
#OPTIONAL:
#  Create a Web Part description file for the Timesheet Status Web Part. To quickly make the file, open Notepad or another text editor, and copy and paste the following text. Add the PublicKeyToken and TypeName values, and then save the file as PWARefWebParts.dwp.

#  Xml Copy Code:
#<?xml version="1.0"?>
#<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
#   <Assembly>PWARefWebParts, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=</Assembly>
#   <TypeName>namespace.classname</TypeName>
#   <Title>Upcoming Tasks</Title>
#   <Description>Shows upcoming tasks for a project.</Description>
#</WebPart>

#  The TypeName element is the class name of the Web Part assembly in the format namespace.classname. For the sample code, the TypeName value is PWARefWebParts.UpcomingTasksWP.

#  If you open the UpcomingTasksWP.cs file in the Visual Studio PWARefWebParts.sln solution file, you can see the namespace is PWARefWebParts. The following line shows the class name is UpcomingTasksWP, and the class inherits from the WebPart class. 
##################################################

5.     Update the configuration file “TSAutoStatus.exe.config”

      <setting name="TimerInterval" serializeAs="String">
        <value>60000</value>
      </setting>
      <setting name="LogFolder" serializeAs="String">
        <value>C:\Program Files\Microsoft\Timesheet Auto Approval Service\Logs</value>
      </setting>
      <setting name="LogTimesheetEvent" serializeAs="String">
        <value>True</value>
      </setting>
      <setting name="LogFileEveryHour" serializeAs="String">
        <value>True</value>
      </setting>
      <setting name="AutomaticallySubmitStatusUpdate" serializeAs="String">
        <value>True</value>
      </setting>
      <setting name="HostName" serializeAs="String">
        <value />
      </setting>
      <setting name="StartTime" serializeAs="String">
        <value></value>
      </setting>
      <setting name="ProcessingDuration" serializeAs="String">
        <value>0</value>
      </setting>
      <setting name="PWASSPName" serializeAs="String">
        <value><%your Shared Services%></value>
      </setting>
      <setting name="DatabaseServer" serializeAs="String">
        <value><%your SQL Server DB%></value>
      </setting>
      <setting name="DatabaseName" serializeAs="String">
        <value><%your PWA Project Server Reporting DB%></value>
      </setting>
      <setting name="PSURL" serializeAs="String">
        <value>http://<%your PWA site%></value>
      </setting>

_____________________________________________________________________________

7.     Go to C:\Program Files\Microsoft Office Servers\12.0\Bin and open Microsoft.Office.Project.Server.Eventing.exe.config in Notepad.exe.  Update the file with the following information:

  <appSettings>
    <add key="DBServer" value="[SQL SERVER NAME]" />
    <add key="DBName" value="[REPORTING SERVER NAME]" />
    <add key="LogTimesheetEvent" value="True" />
    <add key="LogFileEveryHour" value="True" />
    <add key="LogFolderPath" value="C:\Program Files\Microsoft\Timesheet Auto Approval Service\Logs\" />
    <add key="PWASSPName" value="[SHARED SERVICES NAME]" />
    <add key="AutomaticallySubmitStatusUpdate" value="True" />
  </appSettings>

8.     Restart the “Microsoft Office Project Server Events” Service.
9.     Start the “Microsoft Office Project Server Timesheet Auto Approval” Service.
10.     As the Administrator of the Project Server go to [Server Settings]>[Server-Side Event Handler Configuration] to register the Custom Event Handler in PWA.  Scroll down the list of Events and select the following (you can only modify the information for these events one at a time):

Timesheet - LineApproving
Timesheet - Updating
Timesheet - Updated
Timesheet - Submitting

When an Event is selected, click on New Event Handler at the bottom of the screen and enter the following values:

Name:          TimesheetEvent [Event Name]
Description:   Automatically associates Timesheet data with Tasks
Assembly Name: TimesheetEvent, Version=1.0.0.0, Culture=neutral, PublicKeyToken=[Token]
Class Name:    Microsoft.EPM.Events.TimesheetEvent.TSOnUpdated
Order:         1
 
11.     Grant execute permissions to the “Public” role within the Project Server reporting database;

The solution was now successfully installed!

Oct 14, 2008 at 1:34 PM
Regarding lastashes directions to "go to the Reporting Database for the PWA.  Add the Application server as a user with full/every permissions."  Could someone tell me specifically what to do to perform this step.
Thanks
Oct 21, 2008 at 8:01 PM
First, thank you all for this solution.

I am having one last issue.  The processing event is not firing.  The specifics of my issue are as follows:
* the tsAutoStatus table dateProcessed is Null
* I have tried both blanks and a specific time in TSAutoStatusing.exe.config
* the time is not going to the PM for approval
* the time sheet is going to the timesheet manager (TM)  for approval (the TM approves some and rejects some and leaves some open)
* I run TestApp.exe in the package install ==> the dateProcessed column is dated and the time sent to the PM for approavl
* I create some more time sheets ==> dateProcessed remains null
* I run TSAutoStatus.exe and receive the following message:
              "Cannot start service from the command line or a debugger. A Windows Service must first be installed (using installutil.exe) and then started with....."
* I have stopped and started both the following services multiple times:
     * Microsoft Office Project Server Events Service
     * Microsoft Office Project Server Timesheet Auto Approval Service

Am I missing another service?  Do I need to start some scheduler? 

Any help would be appreciated.

Thanks,
Oct 21, 2008 at 10:12 PM
For the above issue, re-booted server and it now works.
Oct 28, 2008 at 7:58 PM

I have gotten this working thanks to all the above instructions.  I have run into 1 problem that may not have been addressed in the design.  Several users are using forms based authentication (LDAP) to access PWA. They authenticate fine and can access and perfrm all PWA functionality.  The problem is that when they submit their timesheet  the following error occurs (Event log)

PSI AUTH: Username 'LDAPMembership:last1fm' passed is not valid in project database.

Urgent - does anyone know how to resolve.

Thanks
Bob P
Oct 30, 2008 at 6:24 AM
Hello All,
We would like to use the timesheet tied mode service and I have already installed it and got it going on our test server.
I would now like to install the latest infrastructure updates and hotfixes for Project Server 2007 / Sharepoint 2007 - can someone tell me whether they are compatible with the tied mode service?
Thanks
Coordinator
Oct 30, 2008 at 6:49 PM
yes it's compatible
Nov 11, 2008 at 8:29 PM

Hi All. I’m experiencing an interesting problem and don’t know if anyone else has seen this recently. I’ve deployed this solution to a set of servers and it was running fine in a distributed mode. However, I installed the infrastructure update and the October rollup for Project Server 2007 and instantly started getting 401.1 errors. So, I simply uninstalled and reinstalled the same solution, however only ran it on one WFE in the farm. This fixed the problem, but then started passing the service account used for impersonation as the timesheet owner. So, I made a change to the stored proc to correct the error by going and finding the owner per TSGUID. That worked great, with no errors for a while.

Now, with no changes to the environment, updates, etc. the application stopped working on the front. No matter what event I configured in the event handler, the process to get and pass timesheet info into the TSAutoStatus has stopped firing. There are no errors in the Event Log, Timesheet Log, ULS Log or SQL logs. It’s almost as though the event handler stopped working and won’t fire the event. I can’t explain what happened and wonder if anyone else has seen this.

As a workaround, I’ve created a set of stored procedures that fire every 15 minutes which check for unprocessed timesheets or timesheets that have been recalled and resubmitted. This stored procedure uses the same service account and writes to the table just fine. Once the timesheets are in the tsAutoStatus table, via stored proc, the rest of the process works fine.  Timesheets import to tasks and submit to status managers and everything works as expected.

Help???

Nov 14, 2008 at 5:53 PM
I'm experiencing something interesting after applying both the Infrastructure Update and August Cumulative update.  We have been using the tied-mode code in our environment since March and all has worked well (as far as we know).  We have MOM set up to alert us of any errors and after applying the updates we have started receiving SOAP exceptions and Cannot Write to a Closed Text Writer messages when our users are entering their timesheets.  All timesheets are to be entered by 10:00am every Friday, so these errors start popping up on Thursday afternoons and until about 10:00am on Friday.  Any ideas or advice on this one?
Dec 5, 2008 at 8:30 PM

Thanks for all the post.  I was finally able to install timesheet tied mode service.  When the timesheet is modified, I see an entry created in the database. But here is the issue I am seeing in the log file:

GeneralItemDoesNotExist

============================
2:15:04 PM: SubmitStatus: True; timesheet URL: http://myserver.com/PWA/_vti_bin/psi/timesheet.asmx; statusing URL: http://myserver.com:56737/SSP2/psi/statusing.asmx
2:15:04 PM:
2:15:04 PM: Total execution time: 0.20 seconds; SubmitStatus: 0.00 seconds

2:15:04 PM: STEP 1 - Initialize Web Service urls
2:15:04 PM: FAILED due to an exception: ==============================
Error:

I do not see any error messages for me to go further.  Has anyone come across this error?

I would really appreciate if some one can help me in this issue.

Thanks in advance for all the help!

MM

Dec 10, 2008 at 6:09 PM
Is it possible to run this on multiple PWA instances within the same physical application server?
Jan 23, 2009 at 5:43 AM
Hi All,

We are considering using this on our single server deployment of PS2007. I do not want the SSH to run for all users, only a select group. They are our technicians, who run a manual system at the moment so there is already a separate approval process. For the balance of our workers we want to run timesheets approval/submission wholly through PWA.

Can I configure it to just work for the technicians?

Cheers,
Jason
Jan 23, 2009 at 11:26 AM
Hi jvanderschyff.
No you can not configure it that way. You will have to modify the code - eighter in the .net code or in the sql trigger.
BR,
Owe

Jan 23, 2009 at 12:12 PM
Hi, I get this error..

Do you know why? Permissions but where? database?

thanks for your time


Event Type:    Error
Event Source:    EPM 2007 Timesheet Event
Event Category:    None
Event ID:    8989
Date:        23-01-2009
Time:        12:07:43
User:        N/A
Computer:    LABSERVER
Description:
FAILED due to a SoapException: ==============================
Error:

System.Web.Services.Protocols.SoapException: ProjectServerError(s) LastError=GeneralSecurityAccessDenied Instructions: Pass this into PSClientError constructor to access all error information
   at Microsoft.Office.Project.Server.WebService.TimeSheet.ReadTimesheet(Guid tsUID)
==============================
PSCLientError Output:
 
GeneralSecurityAccessDenied

============================

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Feb 3, 2009 at 6:53 PM
chrisfie, We are having an issue described earlier in this thread and you discuss the issue is impersonation.  For us not is not occurring every time (mostly it works fine) and only with certain users, so it is impersonating correctly most of the time.

PSError: TimesheetIncorrectPeriod (3208)
Timesheet period used '(null)' is invalid.

There is no difference between users/categories/permissions for those that work vs those that don't, so I am sort of lost.

We are MOSS/MOPS December CU.
Feb 3, 2009 at 7:01 PM
Edited Feb 3, 2009 at 7:04 PM

Make sure that the timesheet line item that you are trying to import has the StandardLineClassUid assigned to it.  By design, these are the only line items that can be imported.

TimesheetConst.const_StandardLineClassGuid

http://msdn.microsoft.com/en-us/library/microsoft.office.project.server.library.timesheetconst.const_standardlineclassguid.aspx

From: cv [mailto:notifications@codeplex.com]
Sent: Tuesday, February 03, 2009 1:53 PM
To:
Subject: Re: Deployment Questions and Issues [AutoStatusService:20566]

 

From: cv

chrisfie, We are having an issue described earlier in this thread and you discuss the issue is impersonation. For us not is not occurring every time (mostly it works fine) and only with certain users, so it is impersonating correctly most of the time.

PSError: TimesheetIncorrectPeriod (3208)
Timesheet period used '(null)' is invalid.

There is no difference between users/categories/permissions for those that work vs those that don't, so I am sort of lost.

We are MOSS/MOPS December CU.

Read the full discussion online.

To add a post to this discussion, reply to this email (AutoStatusService@discussions.codeplex.com)

To start a new discussion for this project, email AutoStatusService@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Feb 3, 2009 at 7:07 PM
Could this be that the user does not have any project tasks in the timesheet and only administrative?
Feb 3, 2009 at 7:13 PM

Yes.

Neither Administrative OR Light Weight project time are associated with the Standard Line Classification.  Therefore, both of these line items will blow up if you attempt to import them.

From: cv [mailto:notifications@codeplex.com]
Sent: Tuesday, February 03, 2009 2:08 PM

Subject: Re: Deployment Questions and Issues [AutoStatusService:20566]

From: cv

Could this be that the user does not have any project tasks in the timesheet and only administrative?

Read the full discussion online.

To add a post to this discussion, reply to this email (AutoStatusService@discussions.codeplex.com)

To start a new discussion for this project, email AutoStatusService@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Feb 20, 2009 at 11:05 PM

Hi All

Thx for your valuable inputs.
I could sucessfully deployed Tied-Mode time sheet solution. Seems like it's working fine too. But, when I checked the Logs, I saw these errors...... can someone provide some help or highlight...what's about n' how to fix it.

4:52:20 PM: STEP 1 - Initialize Web Service urls
4:52:20 PM: STEP 2 - Start event override for timesheet UID: 28584d19-d65c-4882-b63b-b7d439b2dd25
4:52:20 PM: STEP 3 - Statusing Impersonation for RES_UID: 98026b2d-a6f3-4eb7-9457-830ae023c4c6
4:52:20 PM: STEP 4 - Imported Timesheet: My Timesheet; Resource: Admin Test; Creator: Admin Test, TotalActValue: 8.00, Period: 5557fb68-fe31-449f-b381-2c18c8dd8a70
4:52:20 PM: Timesheet line: 5; Project: PS_Test12; Assignement: Test this 2; Actual Work: 2.00
4:52:20 PM: Timesheet line: 6; Project: PS_Test12; Assignement: Timesheet Auto Test_1; Actual Work: 2.00
4:52:20 PM: Timesheet line: 7; Project: PS_Test12; Assignement: Timesheet Auto Test_2; Actual Work: 6.00
4:52:21 PM: STEP 5 - SubmitStatus for: 3 assignments
4:52:21 PM: SUCCESSFULY executed custom timesheet event OnUpdated
4:52:21 PM: Total execution time: 0.25 seconds; SubmitStatus: 0.06 seconds

4:57:21 PM: STEP 1 - Initialize Web Service urls
4:57:21 PM: FAILED due to an exception: ==============================
Error:
System.Web.Services.Protocols.SoapException: ProjectServerError(s) LastError=GeneralItemDoesNotExist Instructions: Pass this into PSClientError constructor to access all error information at Microsoft.Office.Project.Server.WebService.TimeSheet.ReadTimesheet(Guid tsUID)

==============================

Also, some high-light on this step: --- Set execute rights on the tsXXX stored procedures - grant to ProjectServerRole. Where are they?

Regards
Srr

Feb 22, 2009 at 4:31 PM

Hi Srr.

My guess is that the timesheet that is about to be processed has one or more tasks that are no longer in the plan. Or the timesheet has been deleted. You should try to review the timesheet tasks and their counterparts in the project plan.

The tsXXX stored procedures can be found in the database where you installed tiedmode to. Generally this is ProjectServer_Reporting database.

BR,

Owe

Från: srr [mailto:notifications@codeplex.com]
Skickat: den 21 februari 2009 00:05
Till: Evans, Owe
Ämne: Re: Deployment Questions and Issues [AutoStatusService:20566]

From: srr

Hi All

Thx for your valuable inputs.
I could sucessfully deployed Tied-Mode time sheet solution. Seems like it's working fine too. But, when I checked the Logs, I saw these errors...... can someone provide some help or highlight...what's about n' how to fix it.

4:52:20 PM: STEP 1 - Initialize Web Service urls
4:52:20 PM: STEP 2 - Start event override for timesheet UID: 28584d19-d65c-4882-b63b-b7d439b2dd25
4:52:20 PM: STEP 3 - Statusing Impersonation for RES_UID: 98026b2d-a6f3-4eb7-9457-830ae023c4c6
4:52:20 PM: STEP 4 - Imported Timesheet: My Timesheet; Resource: Admin Test; Creator: Admin Test, TotalActValue: 8.00, Period: 5557fb68-fe31-449f-b381-2c18c8dd8a70
4:52:20 PM: Timesheet line: 5; Project: PS_Test12; Assignement: Test this 2; Actual Work: 2.00
4:52:20 PM: Timesheet line: 6; Project: PS_Test12; Assignement: Timesheet Auto Test_1; Actual Work: 2.00
4:52:20 PM: Timesheet line: 7; Project: PS_Test12; Assignement: Timesheet Auto Test_2; Actual Work: 6.00
4:52:21 PM: STEP 5 - SubmitStatus for: 3 assignments
4:52:21 PM: SUCCESSFULY executed custom timesheet event OnUpdated
4:52:21 PM: Total execution time: 0.25 seconds; SubmitStatus: 0.06 seconds

4:57:21 PM: STEP 1 - Initialize Web Service urls
4:57:21 PM: FAILED due to an exception: ==============================
Error:
System.Web.Services.Protocols.SoapException: ProjectServerError(s) LastError=GeneralItemDoesNotExist Instructions: Pass this into PSClientError constructor to access all error information at Microsoft.Office.Project.Server.WebService.TimeSheet.ReadTimesheet(Guid tsUID)

==============================

Also, some high-light on this step: --- Set execute rights on the tsXXX stored procedures - grant to ProjectServerRole. Where are they?

Regards
Srr

Read the full discussion online.

To add a post to this discussion, reply to this email (AutoStatusService@discussions.codeplex.com)

To start a new discussion for this project, email AutoStatusService@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Mar 24, 2009 at 7:18 PM
I have a Web Tier server with several different instances of PWA but only one SSP on an application server. I'm getting an Cannot connect to remote server error and it seems to be because the URL is not correct since everything is not on one server. Howo can I correct this? I assume it's somewhere in this part of the code:

private

string WSUrl(SPSite ss, string wsName, bool impersonate)

 

{

 

if (impersonate)

 

 

return string.Format("{0}//{1}:56737/{2}/psi/{3}.asmx",

 

ss.Protocol, ss.HostName, sspName, wsName);

 

else

 

 

return string.Format("{0}/_vti_bin/psi/{1}.asmx",

 

ss.Url, wsName);

}



Thanks!!
Jun 12, 2009 at 4:35 PM

We completed the installation of the MSI. We went through the checklists provided in this thread. We had an MS consultant review the installation. We rebooted the machine.

Nothing appears to happen. The logs are empty. Saving a timesheet does not appear to invoke any action, even though the events are in place. There are no errors on the server, yet the service is running.

Has 3 of us stumped.

Jun 12, 2009 at 4:43 PM

Chris:

Do any rows get written to the tsAutoStatus table in the reporting database? If not, then the problem is in the event and the event configuration. If there are rows, look at the Dataprocessed and datefailed columns. If either of those are non-null, then the TSAutoService is running and making changes to the db.

Also, look in the application event log on the server for errors.

Post the results of the above for more tips on where to look next.

 

James Fraser

Jun 16, 2009 at 11:11 PM

No rows have been written to the tsAutoStatus table in the reporting database.

Will recheck the event and the event configuration, but it looks like the example (and we checked the Public Key Token). What I have entered is "TimesheetEvent, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1c3c442d16e0416b".

The following events are set:

  • Timesheet - LineApproving
  • Timesheet - Updating
  • Timesheet - Updated
  • Timesheet – Submitting

The application event log on the server is not showing any errors.

Jun 16, 2009 at 11:36 PM

 

I would next restart the Microsoft Office Project Server Eventing Service, and then look in the Application Event log for entries that might get created during start up. The start of this service is when the event handler reads its configuration. Also take a look at the Microsoft.Office.Project.Server.Eventing.exe.config file in the Project Server directory. This should have some lines indicating the reporting DB information. The syntax of these lines can be found in the documentation.

 

James Fraser

Aug 21, 2009 at 5:44 AM

Hello all,

I tried running the MSI Setup, but it keeps failing. The error message I get is "Event Handler Registration Failed. The request failed with HTTP Status 401: Unauthorized". I am using the SSP account and it has appropriate DB and Project Server rights. It is a single server installation. Have I missed something?

Thanks

 

SJ

Sep 9, 2009 at 10:33 AM

Hello,

I have install the solution with the parameter ProcessingDuration = 8.

Now in the tsAutoStatus table, I got a line for the importation of a timesheet with the following value : dateCreated = 03.08.2009 11:07:00, dateProcessed = 10.08.2009 14:53:00, dateFailed= 10.08.2009 14:52:00.

How should I interpret this: does it mean that the importation has definitively failed (as dateFailed is not NULL) ? Does it means that the importation was done as dateProcessed is not NULL ? Why are both dateFailed and dateProcessed filled ?

What is the exact explanation of the parameter ProcessingDuration ?

Thanks,

Alain.

Sep 9, 2009 at 1:46 PM

 

Alain,

DateCreated is the time that a record (line) was created, and should never be null. DateProcessed is the time that a record was processed. DateFailed is the last time that a record failed to process. It should not normally be before the dateProcessed. The details you provided indicated that the record failed, maybe more than once before being successfully processed. Valid states are for DateFailed and DateProcessed to both be null, to both have values, or for either one to be null.

Sometimes records will fail indefinitely. Putting a value in DateProcessed will stop the service from trying to process them.

I'm pretty sure that ProcessingDuration is documented in the install doc. It is the number of hours for which to process records. The service is designed so that it will be easy to configure to have it process records only overnight. There is another parameter that indicates the starting time for this.

 

Hope this helps...

James Fraser

Sep 15, 2009 at 10:33 PM

I'm installing into the latest VPC which is, I think, Project Server 2007 SP2 (Database version says 12.0.6503.5000).  I wanted to give it a go before trying on customer site.

I got the same problem as janshazia - "Event Handler Registration Failed. The request failed with HTTP Status 401: Unauthorized".  I'm logged in as farmadmin - which is the SSP administrator, PWA administrator, system administrator.  I can get to Event Handler registration manually through PWA.

After installation completed, apparently successfully, I had no event handlers set, but also no new service, no registry entry etc.  During the installation I was prompted for, and put in, the Service Login.

I tried the installation again, selected Repair, and got the message "Event Handler registration failed.  Invalid URI:  The format of the URI could not be determined."

Gave up.

Denis

 

 

Mar 2, 2010 at 10:28 PM

Has anyone deleted a row from the dbo.tsAutoStatus table?  Is it ok to do so if a row in the table is causing errors, or will deleting a row cause problems?

 

I'm getting about 20 errors logged every minute because of 4 lines in the table.  It's an "Unauthorized" error.  Go here to see the whole situation, if you want to: http://autostatusservice.codeplex.com/Thread/View.aspx?ThreadId=203571

Thanks to anyone who can help!

Mar 2, 2010 at 10:44 PM

Deleting a row from tsAutostatus will not cause problems, but the Timesheet Import service will not try to import the associated Timesheet. This service will no longer know that the timesheet was editted.

Mar 2, 2010 at 10:48 PM
Tasita wrote:

Has anyone deleted a row from the dbo.tsAutoStatus table?  Is it ok to do so if a row in the table is causing errors, or will deleting a row cause problems?

I'm getting about 20 errors logged every minute because of 4 lines in the table.  It's an "Unauthorized" error.  Go here to see the whole situation, if you want to: http://autostatusservice.codeplex.com/Thread/View.aspx?ThreadId=203571

Thanks to anyone who can help!

 I ended up changing the username on the affected rows to the timesheet owners name.  This stopped the errors!  Thanks, jbfraser!

Feb 20, 2014 at 8:33 AM
Edited Feb 20, 2014 at 8:37 AM
Gendalf wrote:
14:08:52: STEP 1 - Initialize Web Service urls 14:08:52: STEP 2 - Start event override for timesheet UID: ad945c50-4aae-4d49-bd5a-66342563ef79 14:08:52: STEP 3 - Statusing Impersonation for RES_UID: cf91e231-8a1e-49a0-834c-eb57bda934fa 14:08:53: FAILED due to an exception: The request failed with HTTP status 404: Not Found. 14:08:53: SubmitStatus: True; timesheet URL: http://st-it/PWA/_vti_bin/psi/timesheet.asmx; statusing URL: http://st-it:56737/SharedServices/psi/statusing.asmx 14:08:53: Timesheet: Мое расписание; Resource: ST_Resource_1; Creator: ST_Resource_1, Period: c9107b82-3c9d-4729-9190-9b4daa1583b5 14:08:53: Total execution time: 1,48 seconds; SubmitStatus: 0,00 seconds I have this error. Who know the reason?
For the few of you out there still using Project Server 2007: here's a simple solution to this problem.

Timesheet OnUpdated fails:
8:24:29 AM /pwa: STEP 2 - Start event override for timesheet UID: d585fea8-3aa1-4529-bd61-a6c6689759cd
8:24:31 AM /pwa: STEP 3 - Statusing Impersonation for RES_UID: e6a18133-49bd-413c-b947-cfa154101176
8:24:37 AM /pwa: FAILED to execute custom timesheet event OnUpdated, due to an exception: The request failed with HTTP status 404: Not Found.
8:24:37 AM /pwa: SubmitStatus: False; timesheet URL: http://servername:90/pwa/_vti_bin/psi/timesheet.asmx; statusing URL: http://servername:56737//psi/statusing.asmx
8:24:37 AM /pwa: Timesheet: My Timesheet; Resource: TestUser; Creator: TestUser, Period: b6872fc3-84e7-4e2f-b390-6e9f8117d451
8:24:37 AM /pwa: Total execution time: 23.50 seconds; SubmitStatus: 0.00 seconds
Out of the 2 URLs listed, the one failing appeared to be http://servername:56737//psi/statusing.asmx. Since double dashes are out of place here, a variable must be missing.

Solution discovered:

Configuration file Microsoft.Office.Project.Server.Eventing.exe.config in directory C:\Program Files\Microsoft Office Servers\12.0\Bin contained an empty variable “PWASSPNAME” (Project Web App Shared Services Provider). Knowing this variable (“SharedServicesProvider”), it turned out adding it between the dashes in the faulty URL directed us to a working service. The configuration file was updated:
<add key="PWASSPNAME" value="SharedServicesProvider" />
Status updates are now successfully triggered:
9:09:48 AM /pwa: STEP 2 - Start event override for timesheet UID: 9e5789c7-2beb-4ef5-9684-56042a00bc8a
9:09:48 AM /pwa: STEP 3 - Statusing Impersonation for RES_UID: e6a18133-49bd-413c-b947-cfa154101176
9:09:50 AM /pwa: STEP 4 - Imported Timesheet: My Timesheet; Resource: TestUser; Creator: TestUser, TotalActValue: 20.00, Period: a93d1d79-cb6a-4c11-adbb-7c7e697a3e0b
9:09:50 AM /pwa:    Timesheet line: 0; Project: ProjectName; Assignement: TaskName; Actual Work: 20.00
9:09:55 AM /pwa: STEP 5 - SubmitStatus for: 1 assignments
9:09:55 AM /pwa: SUCCESSFULY executed custom timesheet event OnUpdated
9:09:55 AM /pwa: Total execution time: 19.15 seconds; SubmitStatus: 5.87 seconds