Polling on the server

Nov 21, 2008 at 6:32 PM

Our server guy is banging on us because everytime a user opens a new email it polls the server and right now our small pilot is generating a lot of activty on the server as users send out emails.  The polling is showing up in the security logs of the server as activities and it has increased the load on the server.

Our server guy asked if their was any way that the addin could cache its credentials to basically say yes you are secure for todays sessions with the server and it would reduce the polling.

Nov 22, 2008 at 3:08 PM
Edited Nov 22, 2008 at 3:34 PM

Unless I have misunderstood your point, I do not see how this can be related in any way to Velodoc Outlook Add-In and/or Velodoc XP Edition, which I assume you are using considering your other questions in this forum.

Contrary to Velodoc Enterprise Edition, there is no user authentication in Velodoc XP Edition.  Velodoc XP Edition only runs under the identity of the ASPNET (Wndows XP) or NETWORK SERVICE (Windows Server 2003, Vista and Windows Server 2008) windows account. So when executing Velodoc XP Edition on a server, the only security logs you might record shall relate to ASPNET or NETWORK SERVICE.

Velodoc Outllook Add-In is consituted of a Visual Studio Tools for Office (VSTO) Add-In which runs in the Outlook process and the transfer controller which runs as a separate process. The VSTO Add-in only communicates with the transfer controller through .NET remoting, i.e. there is no possible communication between the VSTO Add-In and a file server (FTP or Velodoc XP). The transfer controller loads plug-ins which implement transfer protocols. We have a plug-in for FTP and another one for Velodoc XP Edition (actually using WCF streaming) among others. Only the plug-ins know how to communicate with a file server.

  1. You say "everytime a user opens a new email it polls the server". When opening an email, the VSTO Add-In does not communicate with the Transfer Controller, which does not communicate with the server either (via the designated plug-in). The communication with the server only occurs when the user actually transfers a package.
  2. You also say "Our server guy asked if their was any way that the addin could cache its credentials", but there are no credentials to cache. When the Velodoc XP plug-in calls http://<yourdomain>/VelodocXP/wcfTransferService.svc to execute a transfer (when a user sends an email with a Velodoc package), the user is not authenticated by Windows. Only the web service checks that the email and key passed are correct but this is done under the credentials of ASPNET or NETWORK SERVICE. If you need to be convinced, note that Windows Authentication does not work over the Internet and you can use the Velodoc Outlook Add-In from home to send files using a remote Velodoc XP Edition server.

To confirm everything I have said, please find below the four logs that I get when opening a new Outlook message, adding a package and sending this package with Velodoc Outlook Add-In and Velodoc XP Edition, considering we are only logging the default security events:

Client Security Log (Vista SP1 + Office 2007 + Velodoc Outlook AddIn)
Audit Success    22/11/2008 15:56:40    Eventlog    1102    Log clear

Server Security Log (Windows Server 2008 + IIS 7 + Velodoc XP Edition)
Audit Success    22/11/2008 15:51:25    Eventlog    1102    Log clear

IIS 7 Log (on the server)
#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2008-11-22 15:57:43
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2008-11-22 15:57:43 POST /VelodocXP/wcfTransferService.svc - 80 - - 202 0 0 11310

Network Monitor Log (on the server)
3    295.994920        {HTTP:5, TCP:4, IPv4:3}    NB-VISTA-01    HTTP    HTTP:Request, POST /VelodocXP/wcfTransferService.svc
4    297.539323        {HTTP:5, TCP:4, IPv4:3}    NB-VISTA-01    HTTP    HTTP:HTTP Payload, URL: /VelodocXP/wcfTransferService.svc
5    297.601723        {HTTP:5, TCP:4, IPv4:3}    NB-VISTA-01    HTTP    HTTP:HTTP Payload, URL: /VelodocXP/wcfTransferService.svc
6    297.601723        {HTTP:5, TCP:4, IPv4:3}    NB-VISTA-01    HTTP    HTTP:HTTP Payload, URL: /VelodocXP/wcfTransferService.svc
7    297.601723        {HTTP:5, TCP:4, IPv4:3}    NB-VISTA-01    HTTP    HTTP:HTTP Payload, URL: /VelodocXP/wcfTransferService.svc
8    307.117740        {HTTP:5, TCP:4, IPv4:3}    NB-VISTA-01      HTTP    HTTP:Response, HTTP/1.1, Status Code = 202, URL: /VelodocXP/wcfTransferService.svc

Nov 27, 2008 at 5:47 PM

I sent you response to our server guy and below is his response


they are saying it is the vsto, the wcf and .net framework that would be causing it but lets entertain it for a moment. so every time i open an outlook message every server i have in the domain should then be getting these entries in the logs... they are not.

only the server where velodoc lives gets the auth traffic everytime i open an outlook message with the velodoc plug in ? yes, but it is the vsto etc etc not velodoc in anyway......  

So here is the bottom line - i open an outlook message without the addin installed and i receive no traffic to the server, i open a message up WITH the velodoc addin installed and i get traffic.  
As for enterprise it uses bits, which would be much better in our environment.
in its simplest form however, if you run an addin within office (and i have developed one or two addins in my life) the traffic will show up as the user that the addin is being executed by (pretty standard stuff) . when the message opens if i am getting logs for successful login guess what-- the addin is what is doing it. 
Nov 28, 2008 at 10:49 AM
Edited Dec 8, 2008 at 8:30 PM

On one hand, I would be more than happy to solve this issue but your IT technicians are not giving me much to work with.

On the other hand, I know the following for facts:
  1. I have spent quite some time trying to reproduce what your IT technicians say without success, as shown in the logs I have posted here above (although I am not sure without a proper description of your environment that the platform we use is relevant to reproduce this issue);
  2. I cannot see in our code anything that would trigger a user windows authentication when opening an Outlook email (and doing nothing else as they say). This can easily be verified considering our code is open-source. Besides they say "if you run an addin within office [...] the traffic will show up as the user that the addin is being executed by (pretty standard stuff) . when the message opens if i am getting logs for successful login guess what-- the addin is what is doing it" but the add-in is a DLL running in the Outlook process, so it inherits user rights from Outlook without requiring authenticating again, especially considering that Windows user credentials are not used to communicate with Velodoc XP Edition. Besides each "User Name" scope can only authenticate to a resource a single time. It can be authenticated to the local computer once and to each network resource a single time. This single authentication will generally prohibit a user from authenticating a second time to an individual server in a Windows Domain if the user is already authenticated to the Domain or Tree. See http://www.novell.com/coolsolutions/feature/14914.html.
If they want to progress this, your IT technicians need to do their home work and post useful logs here:
  1. We have no description of the environement and we do not know which security events they are recording (security audit policies) and we have performed our tests with the Windows defaults, so there may be events which they get and which did not show up in our logs. Publishing a relevant portion of their security event log here cannot hurt;
  2. It is easy to install Microsoft Network Monitor on a client computer running Outlook with the add-in and record authentication traffic when opening an Outlook message (and nothing else to start with). Again, publishing a relevant portion of these logs can only help understand the issue.
  3. Also publishing the corresponding DebugView trace is very useful to keep track of the test case performed.
I am willing to consider that the Velodoc add-in is responsible for this authentication traffic and make any correction required in our code, but only with the evidence to support it and allow me to reproduce it.