From: cyclon on
Hello,

we have an SBS2008 server, and vista professional pc's.

Our ERP program is based on advantage database server from sybase.
This program is completely installed on SBS2008, to start it on a vista
pc, you only have to doubleclick on the start-icon that is on a network
drive. The program then starts on the vista pc. The only requirement
is that there has to a continuous connection between the vista pc and
the sbs2008 server at all time.

Now it occurs that this program crashes, apparently because this
connection is lost briefly somehow. We have determined that this crash
happens 10 hours after the user has logged on to windows on his vista
pc. It doesn't matter when the ERP program is started. If for example
you log your vista pc on to the sbs2008 server at 8:00 AM, the crash
will happen at +/- 18:00. It does not matter if you have started the
ERP program at 8:30 or at 17:55, if it is running at 18:00, it will
crash.

Our ERP program is the only program that has a problem. Outlook has no
problem when it is connected on exchange server. Word, excel, autocad,
all these programs work fine. Internet explorer : no problem.

The connection between the server and the pc must apparently be broken
very shortly, and be restored immediately.

Does anybody have any idea that could explain this?

Greetings,

Cyclon


From: Cliff Galiher - MVP on
10 hours is the default time that a kerberos ticket is issued for in a
windows Active Directory network. That glitch is not the network dropping,
but is the server replying with an explicit access denied to the client
because the ticket is expired. The client automatically requests a renewal
of the ticket, which is granted, so for most network activities, you never
"see" that renegotiation. A network application *should* be able to
anticipate and accommodate this as this is standard practice in any network.

If, however, this is a non-network app that has been forced into a networked
situation, you'll want to consider setting up a terminal server instead.

-Cliff


"cyclon" <cyclon(a)base.be.invalid> wrote in message
news:mn.6bec7da5542baabe.85122(a)base.be.invalid...
> Hello,
>
> we have an SBS2008 server, and vista professional pc's.
>
> Our ERP program is based on advantage database server from sybase. This
> program is completely installed on SBS2008, to start it on a vista pc, you
> only have to doubleclick on the start-icon that is on a network drive. The
> program then starts on the vista pc. The only requirement is that there
> has to a continuous connection between the vista pc and the sbs2008 server
> at all time.
>
> Now it occurs that this program crashes, apparently because this
> connection is lost briefly somehow. We have determined that this crash
> happens 10 hours after the user has logged on to windows on his vista pc.
> It doesn't matter when the ERP program is started. If for example you log
> your vista pc on to the sbs2008 server at 8:00 AM, the crash will happen
> at +/- 18:00. It does not matter if you have started the ERP program at
> 8:30 or at 17:55, if it is running at 18:00, it will crash.
>
> Our ERP program is the only program that has a problem. Outlook has no
> problem when it is connected on exchange server. Word, excel, autocad, all
> these programs work fine. Internet explorer : no problem.
>
> The connection between the server and the pc must apparently be broken
> very shortly, and be restored immediately.
>
> Does anybody have any idea that could explain this?
>
> Greetings,
>
> Cyclon
>
>
From: cyclon on
Hello,

thanks for your answer. I'll try to find out more about this, cause
I'm not that familiar with windows server.

I don't think there's anything wrong with my application. If I log on
to windows at 08:15, the problem is at 18:15. If I don't run my
application that day, and only start the application at 18:14, it will
crash at 18:15.

The application is a network app, that is made to work with as much
people as you want in the network.

greetings,

cyclon



Cliff Galiher - MVP schreef op 13/05/2010 het volgende :


> 10 hours is the default time that a kerberos ticket is issued for in a
> windows Active Directory network. That glitch is not the network dropping,
> but is the server replying with an explicit access denied to the client
> because the ticket is expired. The client automatically requests a renewal
> of the ticket, which is granted, so for most network activities, you never
> "see" that renegotiation. A network application *should* be able to
> anticipate and accommodate this as this is standard practice in any network.
>
> If, however, this is a non-network app that has been forced into a networked
> situation, you'll want to consider setting up a terminal server instead.
>
> -Cliff
>
>
> "cyclon" <cyclon(a)base.be.invalid> wrote in message
> news:mn.6bec7da5542baabe.85122(a)base.be.invalid...
>> Hello,
>>
>> we have an SBS2008 server, and vista professional pc's.
>>
>> Our ERP program is based on advantage database server from sybase. This
>> program is completely installed on SBS2008, to start it on a vista pc, you
>> only have to doubleclick on the start-icon that is on a network drive. The
>> program then starts on the vista pc. The only requirement is that there
>> has to a continuous connection between the vista pc and the sbs2008 server
>> at all time.
>>
>> Now it occurs that this program crashes, apparently because this connection
>> is lost briefly somehow. We have determined that this crash happens 10
>> hours after the user has logged on to windows on his vista pc. It doesn't
>> matter when the ERP program is started. If for example you log your vista
>> pc on to the sbs2008 server at 8:00 AM, the crash will happen at +/- 18:00.
>> It does not matter if you have started the ERP program at 8:30 or at
>> 17:55, if it is running at 18:00, it will crash.
>>
>> Our ERP program is the only program that has a problem. Outlook has no
>> problem when it is connected on exchange server. Word, excel, autocad, all
>> these programs work fine. Internet explorer : no problem.
>>
>> The connection between the server and the pc must apparently be broken very
>> shortly, and be restored immediately.
>>
>> Does anybody have any idea that could explain this?
>>
>> Greetings,
>>
>> Cyclon
>>
>>


From: cyclon on
Hello,

the problem is solved, it was the default time for the kerberos ticket
that caused the problem. Now we have changed this time, and there is
no longer a problem.

Thank you very much,

greetings,

cyclon



Cliff Galiher - MVP schreef op 13/05/2010 het volgende :


> 10 hours is the default time that a kerberos ticket is issued for in a
> windows Active Directory network. That glitch is not the network dropping,
> but is the server replying with an explicit access denied to the client
> because the ticket is expired. The client automatically requests a renewal
> of the ticket, which is granted, so for most network activities, you never
> "see" that renegotiation. A network application *should* be able to
> anticipate and accommodate this as this is standard practice in any network.


From: Cliff Galiher - MVP on
The default time for a kerberos ticket is set that way for a reason.
Changing this time too much exponentially increases your risk factor and is
an insecure way to operate. Unless it is absolutely necessary, I'd
encourage users to just log out and log back in or push back on the vendor
to fix this bug in their software.

-Cliff


"cyclon" <cyclon(a)base.be.invalid> wrote in message
news:mn.a2bd7da5107f61cd.85122(a)base.be.invalid...
> Hello,
>
> the problem is solved, it was the default time for the kerberos ticket
> that caused the problem. Now we have changed this time, and there is no
> longer a problem.
>
> Thank you very much,
>
> greetings,
>
> cyclon
>
>
>
> Cliff Galiher - MVP schreef op 13/05/2010 het volgende :
>
>
>> 10 hours is the default time that a kerberos ticket is issued for in a
>> windows Active Directory network. That glitch is not the network
>> dropping, but is the server replying with an explicit access denied to
>> the client because the ticket is expired. The client automatically
>> requests a renewal of the ticket, which is granted, so for most network
>> activities, you never "see" that renegotiation. A network application
>> *should* be able to anticipate and accommodate this as this is standard
>> practice in any network.
>
>