none
Project Server 2010, ExchangeSync.asmx RRS feed

  • Question

  • The current setup is a single shard server running up to date installations of Windows Server 2008 r2, SQL 2008 r2, Sharepoint 2010, Project Server 2010. These systems were installed according to technet articles.

    Now to the issues at hand. I`m going to try and explain them on basic interaction I have problem with. What makes me even more curious is the lack of information on the subject, and sometimes even conflicting answers on these forums as seen in the threads linked below.

    The problem is present when you try to use the interaction between Exchange 2010 and Project Server 2010 which directly pushes information to users Outlook 2010 platform.

    The ExchangeSync job is called during these times at the moment

    -Overnight push

    -Using publish after making changes to a project

    The ExchangeSync job should also be called at this time

    -Making changes to task status in Outlook, and using send/receive.

    According to what I read , Exchange should call a webservice ExchangeSync.asmx, when it detects a change in a task status. This call should initiate ExchangeSync job. Thus pushing the change into the Project Server. That should be seen in pwa/project professional after approval.

    At the moment If PM wants to know if the task he assigned is updated. He has to open a unupdated project. Call for publish, close it, and approve the collected tasks. A simple test tells me, that it really should not be this way. When PM creates an autoapprove rule and publishes a project, the exchangesync gets called, processes the task update, however stops and stays in approval queue, as the project was checked out  when the rule was in place. Making the use of rules futile. This makes me convinced about this interaction not being complete.

    Thread saying that only publish call and overnight sync works for the interaction.

    http://social.technet.microsoft.com/Forums/en-AU/projectserver2010general/thread/85775e8b-9f52-4e5c-a88a-f27b47a2fd0c

    Thread saying that the changes in outlook should initiate call from exchange for exchangesync webservice located on projectserver system.

    http://social.technet.microsoft.com/Forums/en-US/projserv2010setup/thread/48244f4e-85d1-419c-955b-c0d82f1f9f52/

    I`m gonna use two examples. One showing what I think it should work like, and one that we currently have to use to utilize the “exchange sync” call.

    How it should work : PM creates a project and builds a team, sets up the dates and project information -> PM creates a task and assigns it to enterprise resource that was used to build a team -> PM publishes the changes -> E-mail notification is sent to PM and Resource -> Task is shown in outlook on Resource side -> Resource changes the task status from 0% to 25% -> Resource uses send/receive call to notify exchange -> PM receives a notification e-mail about the change -> Task update appears in approval center for PM or RM -> PM or RM approves a task -> Task update is shown when project is opened in PWA/Project Professional -> Task update is visible to team members when project is published

    How it should work : PM creates a project and builds a team, sets up the dates and project information -> PM creates a task and assigns it to enterprise resource that was used to build a team -> PM publishes the changes -> E-mail notification is sent to PM and Resource -> Task is shown in outlook on Resource side -> Resource changes the task status from 0% to 25% -> Resource uses send/receive call to notify exchange -> PM has to open a project and use publish -> PM receives a notification e-mail about the change -> PM has to close the project -> Task update appears in approval center for PM or RM -> PM or RM approves a task -> Task update is shown when project is opened in PWA/Project Professional -> Task update is visible to team members when project is published

    Thanks again for any help.

    PS : I wasn`t able to found any worthy errors even in verbose mode of ULS sharepoint



    Thursday, February 2, 2012 10:27 AM

Answers

  • Okay so I`ve fixed the problem, and wanted to share it with others who suffer the same issue.

    There are few logging options to check even when you`re not experiencing the same problem. I suggest using verbose option in sharepoint -> monitoring ->  set logging to verbose for Project Server, and use options available you to in sharepoint shell. You can list errors, or warnings and diagnose any part of the transaction that happens here. Event viewer is a possibility, but you won`t get a full disclosure there. Don`t forget to check IIS logs, as any access that happens on the front-end servers happens there.

    I`ve began my diagnostics on the exchange server, as the issue at hand is caused when the request is sent to a webservice at a location C:\Program Files\Microsoft Office Servers\14.0\WebServices\Shared\ProjectServer\PSI.

    As you can easily check, when you browse this location in IIS , there is no such file available there. However you`ll find exchangesync.svc. That suggest it probably is involved in transaction.

    I was getting an error on the exchange side (or success) in application log. Mine was a 500 server error.

    There are three things I was able to point out, causing this kind of issue.

    1. As the request is made by a Exchange CAS server (In my case, it`s exchange server, since we have a single shard solution) you need to check if “domain\exchange$computer account is granted local rights (added to local user/administrator group)

    2. If a certificate that btsoperation and exchange uses in transaction, available in both instances. Check this through Microsoft management console. Use certificate snap-in and look into personal and trusted root certification authorities.

    3. Last thing and probably the most intriguing is the case of ISS logs on sharepoint front-end. An error was generated there, that said a request from exchange is looking after sendnotification.asmx, rather than exchangesync.asmx. Although it was clearly the request that on the other side generated the warning on exchange server. So I`ve created a copy of exchangesync.svc, and renamed it to sendnotification.svc (which wasn`t there before).

    If any of you gather any other information on the subject, feel free to post here, as it might help others.

    After all these steps my synchronization works perfectly.


     



    • Marked as answer by Eugen Harton Tuesday, February 7, 2012 1:45 PM
    • Edited by Eugen Harton Tuesday, February 7, 2012 2:51 PM
    Tuesday, February 7, 2012 1:45 PM

All replies

  • same experience here!

    according to this TechNet article, Exchange server notifies Project Server to run a job and get data from Exchange server (when an Outlook client changes the assignment data), but it seems that all Exchange Synchronization Jobs run after Publish Job in Project Server (some kind of sequence and dependencies in Project Server Queue Jobs).

    i hope we find a reasonable answer for this behavior through this topic.

    ;)


    ----

    « Accept Me as Me »

    Friday, February 3, 2012 6:47 PM
  • Thanks for the answer, at least I know there is someone else with the same problem out there.

     

    Anybody can at least clarify, it works as is proposed? Or does really everybody just wait for overnight push? Anyone that can provide transaction map for this behaviour, so I can track down the part that might cause this?

     

    Thanks again for any help.

    Monday, February 6, 2012 11:35 AM
  • Okay so I`ve fixed the problem, and wanted to share it with others who suffer the same issue.

    There are few logging options to check even when you`re not experiencing the same problem. I suggest using verbose option in sharepoint -> monitoring ->  set logging to verbose for Project Server, and use options available you to in sharepoint shell. You can list errors, or warnings and diagnose any part of the transaction that happens here. Event viewer is a possibility, but you won`t get a full disclosure there. Don`t forget to check IIS logs, as any access that happens on the front-end servers happens there.

    I`ve began my diagnostics on the exchange server, as the issue at hand is caused when the request is sent to a webservice at a location C:\Program Files\Microsoft Office Servers\14.0\WebServices\Shared\ProjectServer\PSI.

    As you can easily check, when you browse this location in IIS , there is no such file available there. However you`ll find exchangesync.svc. That suggest it probably is involved in transaction.

    I was getting an error on the exchange side (or success) in application log. Mine was a 500 server error.

    There are three things I was able to point out, causing this kind of issue.

    1. As the request is made by a Exchange CAS server (In my case, it`s exchange server, since we have a single shard solution) you need to check if “domain\exchange$computer account is granted local rights (added to local user/administrator group)

    2. If a certificate that btsoperation and exchange uses in transaction, available in both instances. Check this through Microsoft management console. Use certificate snap-in and look into personal and trusted root certification authorities.

    3. Last thing and probably the most intriguing is the case of ISS logs on sharepoint front-end. An error was generated there, that said a request from exchange is looking after sendnotification.asmx, rather than exchangesync.asmx. Although it was clearly the request that on the other side generated the warning on exchange server. So I`ve created a copy of exchangesync.svc, and renamed it to sendnotification.svc (which wasn`t there before).

    If any of you gather any other information on the subject, feel free to post here, as it might help others.

    After all these steps my synchronization works perfectly.


     



    • Marked as answer by Eugen Harton Tuesday, February 7, 2012 1:45 PM
    • Edited by Eugen Harton Tuesday, February 7, 2012 2:51 PM
    Tuesday, February 7, 2012 1:45 PM
  • Thanks Eugen for this find, it helped me in a recent installation.

    Kind regards,
    Adrian

    Thursday, November 21, 2013 2:25 AM