Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

AdsFindServers on Windows 2008 SBS

4 posts in Networking Last posting was on 2011-06-14 15:42:26.0Z
Dusten Scheere Posted on 2011-06-06 19:56:58.0Z
From: "Dusten Scheere" <ddstwo@gofrontline.com>
Newsgroups: Advantage.Networking
Subject: AdsFindServers on Windows 2008 SBS
Date: Mon, 6 Jun 2011 12:56:58 -0700
Lines: 2
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 15.4.3508.1109
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109
NNTP-Posting-Host: 68.14.239.173
Message-ID: <4ded30fb$1@solutions.advantagedatabase.com>
X-Trace: 6 Jun 2011 12:56:43 -0700, 68.14.239.173
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.Networking:952
Article PK: 1132361

Hello All,

We're having a strange issue with the AdsFindServer call on a Windows 2008
SBS machine. It takes exactly 3 minutes for AdsFindServer to give us a
result. This machine is acting as the server and all clients on the network
get a result from AdsFindServer immediately.

Here's an interesting clue. If you call AdsFindServer from the same app
launched a second time while the first one is in that 3 minute window, you
get a result immediately. On the other hand, if you call AdsFindServer, wait
for it to return a handle, and then launch the same app a second time it
will then take 3 minutes to return a result.

We've turned on Network Discovery, and File and Printer Sharing.
We've opened TCP/UDP ports 6262 and UDP ports 2989(this works on all of our
other locations). We've also attempted this with the firewall disabled.
The error logs do not report anything strange.

Any ideas?
Thanks for your time

-- Dusten Scheere
ddstwo@gofrontline.com
Frontline Software Technology, Inc.


Mark Wilkins Posted on 2011-06-07 22:00:24.0Z
From: "Mark Wilkins" <a@b.c>
Newsgroups: Advantage.Networking
References: <4ded30fb$1@solutions.advantagedatabase.com>
In-Reply-To: <4ded30fb$1@solutions.advantagedatabase.com>
Subject: Re: AdsFindServers on Windows 2008 SBS
Date: Tue, 7 Jun 2011 16:00:24 -0600
Lines: 3
Organization: Sybase
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 10.6.199.122
Message-ID: <4dee9f65$1@solutions.advantagedatabase.com>
X-Trace: 7 Jun 2011 15:00:05 -0700, 10.6.199.122
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.Networking:953
Article PK: 1132364

Hi Dusten,

I would suspect that the attempt to connect to the discovered servers is,
for some reason, failing and timing out slowly. Maybe try using it with the
ADS_FS_MULTICAST_ONLY option. That may help narrow it down. If that does
not show the delay, then it would mean that one of the connection attempts
is failing. If so, then you could try connecting individually to each of
the addresses shown in the results to determine which one might be culprit.

I am a little puzzled over the "exactly 3 minutes" part and the fact that
another call to that function during the 3 minutes returns instantly. It's
an excellent clue and I like it very much. But I am unsure how to make use
of it. Does the "instant" result during that 3 minute window have the
correct information in it? It could be that the second attempt is failing
to create and bind to the multicast port while the first call is still
running. If so, then it would (I think) either return an error or an empty
result.

There is an option RETRY_ADS_CONNECTS in the ads.ini file that controls
whether or not a connection to a server will be retried or fail instantly
based on a previous failure. If a failure is such that the client thinks
the server does not exist, for example, then if the retry option is off (the
default), then the next connect attempt will immediately return the previous
error code. So it seems this might somehow come into play here, but it
doesn't make sense to me that the 3 minute delay would return while the app
is still running.

Mark Wilkins
Advantage R&D

"Dusten Scheere" <ddstwo@gofrontline.com> wrote in message
news:4ded30fb$1@solutions.advantagedatabase.com...
> Hello All,
>
> We're having a strange issue with the AdsFindServer call on a Windows 2008
> SBS machine. It takes exactly 3 minutes for AdsFindServer to give us a
> result. This machine is acting as the server and all clients on the
> network get a result from AdsFindServer immediately.
>
> Here's an interesting clue. If you call AdsFindServer from the same app
> launched a second time while the first one is in that 3 minute window, you
> get a result immediately. On the other hand, if you call AdsFindServer,
> wait for it to return a handle, and then launch the same app a second time
> it will then take 3 minutes to return a result.
>
> We've turned on Network Discovery, and File and Printer Sharing.
> We've opened TCP/UDP ports 6262 and UDP ports 2989(this works on all of
> our other locations). We've also attempted this with the firewall
> disabled.
> The error logs do not report anything strange.
>
> Any ideas?
> Thanks for your time
>
> -- Dusten Scheere
> ddstwo@gofrontline.com
> Frontline Software Technology, Inc.


Dusten Scheere Posted on 2011-06-10 15:14:48.0Z
From: "Dusten Scheere" <ddstwo@gofrontline.com>
Newsgroups: Advantage.Networking
References: <4ded30fb$1@solutions.advantagedatabase.com> <4dee9f65$1@solutions.advantagedatabase.com>
In-Reply-To: <4dee9f65$1@solutions.advantagedatabase.com>
Subject: Re: AdsFindServers on Windows 2008 SBS
Date: Fri, 10 Jun 2011 08:14:48 -0700
Lines: 7
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 15.4.3508.1109
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109
NNTP-Posting-Host: 68.14.239.173
Message-ID: <4df234e9$1@solutions.advantagedatabase.com>
X-Trace: 10 Jun 2011 08:14:49 -0700, 68.14.239.173
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.Networking:954
Article PK: 1132363

Hi Mark, thanks for the reply,

We use the ADS_FS_MULTICAST_ONLY option(All we're interested in is the
Server Name). Just for fun I ran a test with ADS_FS_CONNECT_ALL and it still
took 3 minutes to resolve.

I thought the 3 minute thing was very interesting as well. I took your
advice and looked closer at the data being returned and the 'instant' result
does return good data. Well, both calls do eventually return good data.

The RETRY_ADS_CONNECTS didn't seem to have an effect. While I was modifying
the file though I did notice something that may be of help. We had to turn
on MTIER_LOCAL_CONNECTIONS, otherwise AdsFindServers wouldn't work on a
terminal server. This is a 2008 terminal server and the lag does happen when
we remote in. Would it be worth it to have our customer test this by logging
on locally to the server?

And again, all other clients on the network aren't experiencing any
problems. It's only when logged into the server(remotely, we haven't tested
it with a local login) that this starts happening. We have other customers
running Windows 2008 terminal server and haven't experienced this yet at
all. In fact, AdsFindServers has worked really well for us.

Thanks a lot for your help

-- Dusten Scheere
ddstwo@gofrontline.com
Frontline Software Technology, Inc.


"Mark Wilkins" wrote in message
news:4dee9f65$1@solutions.advantagedatabase.com...

Hi Dusten,

I would suspect that the attempt to connect to the discovered servers is,
for some reason, failing and timing out slowly. Maybe try using it with the
ADS_FS_MULTICAST_ONLY option. That may help narrow it down. If that does
not show the delay, then it would mean that one of the connection attempts
is failing. If so, then you could try connecting individually to each of
the addresses shown in the results to determine which one might be culprit.

I am a little puzzled over the "exactly 3 minutes" part and the fact that
another call to that function during the 3 minutes returns instantly. It's
an excellent clue and I like it very much. But I am unsure how to make use
of it. Does the "instant" result during that 3 minute window have the
correct information in it? It could be that the second attempt is failing
to create and bind to the multicast port while the first call is still
running. If so, then it would (I think) either return an error or an empty
result.

There is an option RETRY_ADS_CONNECTS in the ads.ini file that controls
whether or not a connection to a server will be retried or fail instantly
based on a previous failure. If a failure is such that the client thinks
the server does not exist, for example, then if the retry option is off (the
default), then the next connect attempt will immediately return the previous
error code. So it seems this might somehow come into play here, but it
doesn't make sense to me that the 3 minute delay would return while the app
is still running.

Mark Wilkins
Advantage R&D

"Dusten Scheere" <ddstwo@gofrontline.com> wrote in message
news:4ded30fb$1@solutions.advantagedatabase.com...
> Hello All,
>
> We're having a strange issue with the AdsFindServer call on a Windows 2008
> SBS machine. It takes exactly 3 minutes for AdsFindServer to give us a
> result. This machine is acting as the server and all clients on the
> network get a result from AdsFindServer immediately.
>
> Here's an interesting clue. If you call AdsFindServer from the same app
> launched a second time while the first one is in that 3 minute window, you
> get a result immediately. On the other hand, if you call AdsFindServer,
> wait for it to return a handle, and then launch the same app a second time
> it will then take 3 minutes to return a result.
>
> We've turned on Network Discovery, and File and Printer Sharing.
> We've opened TCP/UDP ports 6262 and UDP ports 2989(this works on all of
> our other locations). We've also attempted this with the firewall
> disabled.
> The error logs do not report anything strange.
>
> Any ideas?
> Thanks for your time
>
> -- Dusten Scheere
> ddstwo@gofrontline.com
> Frontline Software Technology, Inc.


Mark Wilkins Posted on 2011-06-14 15:42:26.0Z
From: "Mark Wilkins" <a@b.c>
Newsgroups: Advantage.Networking
References: <4ded30fb$1@solutions.advantagedatabase.com> <4dee9f65$1@solutions.advantagedatabase.com> <4df234e9$1@solutions.advantagedatabase.com>
In-Reply-To: <4df234e9$1@solutions.advantagedatabase.com>
Subject: Re: AdsFindServers on Windows 2008 SBS
Date: Tue, 14 Jun 2011 09:42:26 -0600
Lines: 2
Organization: Sybase
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 10.6.199.122
Message-ID: <4df78156$1@solutions.advantagedatabase.com>
X-Trace: 14 Jun 2011 08:42:14 -0700, 10.6.199.122
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.Networking:955
Article PK: 1132365

Hi Dusten,

It would be interesting to see if logging on locally to the machine changes
it and avoids the 3 minute delay. That would at least help indicate if it
is something specific to the machine itself or some kind of issue with
terminal services.

The code has a loop that sends out multicast requests and waits for a
response. In an error situation, I can definitely see how it would result
in a long timeout. But I have a hard time seeing how the delays in the
loops could ever come out to 180 seconds.

The MTIER_LOCAL_CONNECTIONS setting makes sense, but it didn't occur to us
when implementing that API. It uses a local server connection to create a
temporary table for storing the results of the API.

Mark Wilkins
Advantage R&D

"Dusten Scheere" <ddstwo@gofrontline.com> wrote in message
news:4df234e9$1@solutions.advantagedatabase.com...
> Hi Mark, thanks for the reply,
>
> We use the ADS_FS_MULTICAST_ONLY option(All we're interested in is the
> Server Name). Just for fun I ran a test with ADS_FS_CONNECT_ALL and it
> still took 3 minutes to resolve.
>
> I thought the 3 minute thing was very interesting as well. I took your
> advice and looked closer at the data being returned and the 'instant'
> result does return good data. Well, both calls do eventually return good
> data.
>
> The RETRY_ADS_CONNECTS didn't seem to have an effect. While I was
> modifying the file though I did notice something that may be of help. We
> had to turn on MTIER_LOCAL_CONNECTIONS, otherwise AdsFindServers wouldn't
> work on a terminal server. This is a 2008 terminal server and the lag does
> happen when we remote in. Would it be worth it to have our customer test
> this by logging on locally to the server?
>
> And again, all other clients on the network aren't experiencing any
> problems. It's only when logged into the server(remotely, we haven't
> tested it with a local login) that this starts happening. We have other
> customers running Windows 2008 terminal server and haven't experienced
> this yet at all. In fact, AdsFindServers has worked really well for us.
>
> Thanks a lot for your help
>
> -- Dusten Scheere
> ddstwo@gofrontline.com
> Frontline Software Technology, Inc.
>
>
> "Mark Wilkins" wrote in message
> news:4dee9f65$1@solutions.advantagedatabase.com...
>
> Hi Dusten,
>
> I would suspect that the attempt to connect to the discovered servers is,
> for some reason, failing and timing out slowly. Maybe try using it with
> the
> ADS_FS_MULTICAST_ONLY option. That may help narrow it down. If that does
> not show the delay, then it would mean that one of the connection attempts
> is failing. If so, then you could try connecting individually to each of
> the addresses shown in the results to determine which one might be
> culprit.
>
> I am a little puzzled over the "exactly 3 minutes" part and the fact that
> another call to that function during the 3 minutes returns instantly.
> It's
> an excellent clue and I like it very much. But I am unsure how to make
> use
> of it. Does the "instant" result during that 3 minute window have the
> correct information in it? It could be that the second attempt is failing
> to create and bind to the multicast port while the first call is still
> running. If so, then it would (I think) either return an error or an
> empty
> result.
>
> There is an option RETRY_ADS_CONNECTS in the ads.ini file that controls
> whether or not a connection to a server will be retried or fail instantly
> based on a previous failure. If a failure is such that the client thinks
> the server does not exist, for example, then if the retry option is off
> (the
> default), then the next connect attempt will immediately return the
> previous
> error code. So it seems this might somehow come into play here, but it
> doesn't make sense to me that the 3 minute delay would return while the
> app
> is still running.
>
> Mark Wilkins
> Advantage R&D
>
> "Dusten Scheere" <ddstwo@gofrontline.com> wrote in message
> news:4ded30fb$1@solutions.advantagedatabase.com...
>> Hello All,
>>
>> We're having a strange issue with the AdsFindServer call on a Windows
>> 2008 SBS machine. It takes exactly 3 minutes for AdsFindServer to give us
>> a result. This machine is acting as the server and all clients on the
>> network get a result from AdsFindServer immediately.
>>
>> Here's an interesting clue. If you call AdsFindServer from the same app
>> launched a second time while the first one is in that 3 minute window,
>> you get a result immediately. On the other hand, if you call
>> AdsFindServer, wait for it to return a handle, and then launch the same
>> app a second time it will then take 3 minutes to return a result.
>>
>> We've turned on Network Discovery, and File and Printer Sharing.
>> We've opened TCP/UDP ports 6262 and UDP ports 2989(this works on all of
>> our other locations). We've also attempted this with the firewall
>> disabled.
>> The error logs do not report anything strange.
>>
>> Any ideas?
>> Thanks for your time
>>
>> -- Dusten Scheere
>> ddstwo@gofrontline.com
>> Frontline Software Technology, Inc.
>