Slow Application Access after joining the client to Domain

Hi,
We are seeing a strange problem with one of DB2 Application. The DB2 server runs on an AIV Machine and the DB2 clients run in XP Machines. When the XP machines are part of a workgroup, the DB2 client works just fine i.e. when the user clicks on the application the applictaion credentials windows pops up within 2 seconds, however when the same client is joined to the domain, it takes 60-100 Seconds for the application authetication wlindows to pop up.

I have tried looking at the issue from a DNS Stand point, dont think name resolution is a problem here. The DB2 client is configured to Use DB2 Server IP and a Specific Port, so its more of an IP Communication.

I have take captures of before and after joining the XP client to the domain and noticed that the domain client tries to contact the DC using various protocls like TCP (RPC Communication), MSRPC, LSAT. After LSAT packets i see that the client connect to the application server. I am thinking if any of the domain policies are contributing to the delay. (Note - These captures are talen after the login process is completed).

If it was a IP communication between DB2 client and server, i should have seen packets directly going to the DB2 Client to the DB2 application server and not from the the client to the DC.

I wanted to know what needs to be done to fix this delay...does creating an SPN for the DB2 Server help? The DB2 authetication not integrated with AD and is not an option.

Any ideas would greatly help.

This is worth a shot: Is the DB2 app dependant on NetBIOS/WINS? If so, make
sure it has a proper entry and that your WINS settings are correct on the
WINS server and on the clients (if DHCP, then check DHCP settings also). If
you don't have WINS, put an entry for the DB2 server in the client's LMHOST.

--
Regards,

Mel K.
MCSA: M
"Kerry" <Phanindra@live.com> wrote in message
news:ezfy%23LK7JHA.3304@TK2MSFTNGP06.phx.gbl...
Hi,
We are seeing a strange problem with one of DB2 Application. The DB2 server
runs on an AIV Machine and the DB2 clients run in XP Machines. When the XP
machines are part of a workgroup, the DB2 client works just fine i.e. when
the user clicks on the application the applictaion credentials windows pops
up within 2 seconds, however when the same client is joined to the domain,
it takes 60-100 Seconds for the application authetication wlindows to pop
up.

I have tried looking at the issue from a DNS Stand point, dont think name
resolution is a problem here. The DB2 client is configured to Use DB2 Server
IP and a Specific Port, so its more of an IP Communication.

I have take captures of before and after joining the XP client to the domain
and noticed that the domain client tries to contact the DC using various
protocls like TCP (RPC Communication), MSRPC, LSAT. After LSAT packets i see
that the client connect to the application server. I am thinking if any of
the domain policies are contributing to the delay. (Note - These captures
are talen after the login process is completed).

If it was a IP communication between DB2 client and server, i should have
seen packets directly going to the DB2 Client to the DB2 application server
and not from the the client to the DC.

I wanted to know what needs to be done to fix this delay...does creating an
SPN for the DB2 Server help? The DB2 authetication not integrated with AD
and is not an option.

Any ideas would greatly help.

Try opening Network Connections Windows (talking XP here), highlight the LAN
connection and select the "ADVANCED" menu across the top, the go to "Advanced
Settings" and optimise the binding order by removing unnecessary protocols,
and then under providers, move "MS Windows Network to 1st position". I've
seen this work before. I think that MEL K's hit the Nail on the Head though.
--
Garry Starck
MCITP, MCTS AD, MCSE 2003 Messaging, MCDBA


"Mel K." wrote:

> This is worth a shot: Is the DB2 app dependant on NetBIOS/WINS? If so, make
> sure it has a proper entry and that your WINS settings are correct on the
> WINS server and on the clients (if DHCP, then check DHCP settings also). If
> you don't have WINS, put an entry for the DB2 server in the client's LMHOST.
>
> --
> Regards,
>
> Mel K.
> MCSA: M
> "Kerry" <Phanindra@live.com> wrote in message
> news:ezfy%23LK7JHA.3304@TK2MSFTNGP06.phx.gbl...
> Hi,
> We are seeing a strange problem with one of DB2 Application. The DB2 server
> runs on an AIV Machine and the DB2 clients run in XP Machines. When the XP
> machines are part of a workgroup, the DB2 client works just fine i.e. when
> the user clicks on the application the applictaion credentials windows pops
> up within 2 seconds, however when the same client is joined to the domain,
> it takes 60-100 Seconds for the application authetication wlindows to pop
> up.
>
> I have tried looking at the issue from a DNS Stand point, dont think name
> resolution is a problem here. The DB2 client is configured to Use DB2 Server
> IP and a Specific Port, so its more of an IP Communication.
>
> I have take captures of before and after joining the XP client to the domain
> and noticed that the domain client tries to contact the DC using various
> protocls like TCP (RPC Communication), MSRPC, LSAT. After LSAT packets i see
> that the client connect to the application server. I am thinking if any of
> the domain policies are contributing to the delay. (Note - These captures
> are talen after the login process is completed).
>
> If it was a IP communication between DB2 client and server, i should have
> seen packets directly going to the DB2 Client to the DB2 application server
> and not from the the client to the DC.
>
> I wanted to know what needs to be done to fix this delay...does creating an
> SPN for the DB2 Server help? The DB2 authetication not integrated with AD
> and is not an option.
>
> Any ideas would greatly help.
>
>
>

"Kerry" <Phanindra@live.com> wrote in message
news:ezfy%23LK7JHA.3304@TK2MSFTNGP06.phx.gbl...
> Hi,
> We are seeing a strange problem with one of DB2 Application. The DB2
> server
> runs on an AIV Machine and the DB2 clients run in XP Machines. When the XP
> machines are part of a workgroup, the DB2 client works just fine i.e. when
> the user clicks on the application the applictaion credentials windows
> pops
> up within 2 seconds, however when the same client is joined to the domain,
> it takes 60-100 Seconds for the application authetication wlindows to pop
> up.
>
> I have tried looking at the issue from a DNS Stand point, dont think name
> resolution is a problem here. The DB2 client is configured to Use DB2
> Server
> IP and a Specific Port, so its more of an IP Communication.
>
> I have take captures of before and after joining the XP client to the
> domain
> and noticed that the domain client tries to contact the DC using various
> protocls like TCP (RPC Communication), MSRPC, LSAT. After LSAT packets i
> see
> that the client connect to the application server. I am thinking if any of
> the domain policies are contributing to the delay. (Note - These captures
> are talen after the login process is completed).
>
> If it was a IP communication between DB2 client and server, i should have
> seen packets directly going to the DB2 Client to the DB2 application
> server
> and not from the the client to the DC.
>
> I wanted to know what needs to be done to fix this delay...does creating
> an
> SPN for the DB2 Server help? The DB2 authetication not integrated with AD
> and is not an option.
>
> Any ideas would greatly help.
>



In addition to Mel and Garry's suggestions, I would also make sure that the
internal DNS servers are the only ones configured in IP properties. I
usually see similar issues once a machine is joined with a domain with ther
members (DCs and workstations) have been misconfigured to use their ISP's
DNS address, or the router's. Other contributing things can be, other than
lack of WINS address or using WINS and no entry in WINS (Mel's concerns),
multihomed DCs (Garry's concerns falls under this with the binding order)
that require additional configuration changes on the DC to make it function
properly, single label name domain ('domain' vs the required minimum of
'domain.com').


--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
aceman@mvps.RemoveThisPart.org

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right
things." - Peter F. Drucker
http://twitter.com/acefekay

I do not see any netbios sessions at all in the network capture. When in workgroup, the moment i click on the application its a straight TCP Connection from DB2 Client Src Port 1039 to DB2 Server on Dest Port 50000 (This port is hard coded in the client side).

When the same machine joins to the domain, the moment i click the application, it sends some RPC Packets to the DC and then i see some LSAT frames. I saw these frames and kind of think this is where the issue may be:

First time 3-way Handshake
8 0.000000 {TCP:6, IPv4:5} DB2 Client AD DC TCP TCP:Flags=......S., SrcPort=1074, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=2880073679, Ack=0, Win=65535 ( ) = 65535
9 0.000000 {TCP:6, IPv4:5} AD DC DB2 Client TCP TCP:Flags=...A..S., SrcPort=DCE endpoint resolution(135), DstPort=1074, PayloadLen=0, Seq=2774228518, Ack=2880073680, Win=16384 ( Scale factor not supported ) = 16384
10 0.000000 {TCP:6, IPv4:5} DB2 Client AD DC TCP TCP:Flags=...A...., SrcPort=1074, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=2880073680, Ack=2774228519, Win=65535 (scale factor 0x0) = 65535

RPC Bind to the Endpoint Mapper
11 0.000000 {MSRPC:7, TCP:6, IPv4:5} DB2 Client AD DC MSRPC MSRPC:c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT Call=0xD Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
12 0.000000 {MSRPC:7, TCP:6, IPv4:5} AD DC DB2 Client MSRPC MSRPC:c/o Bind Ack: Call=0xD Assoc Grp=0x2481B8 Xmit=0x16D0 Recv=0x16D0

End point Map Request to the Application
13 0.000000 {MSRPC:7, TCP:6, IPv4:5} DB2 Client AD DC EPM EPM:Request: ept_map:
14 0.000000 {MSRPC:7, TCP:6, IPv4:5} AD DC DB2 Client EPM EPM:Response: ept_map:


Second time 3-way Handshake

15 0.000000 {TCP:8, IPv4:5} DB2 Client AD DC TCP TCP:Flags=......S., SrcPort=1075, DstPort=GENA(5000), PayloadLen=0, Seq=3342506103, Ack=0, Win=65535 ( ) = 65535
16 0.000000 {TCP:8, IPv4:5} AD DC DB2 Client TCP TCP:Flags=...A..S., SrcPort=GENA(5000), DstPort=1075, PayloadLen=0, Seq=1515412576, Ack=3342506104, Win=16384 ( Scale factor not supported ) = 16384
17 0.000000 {TCP:8, IPv4:5} DB2 Client AD DC TCP TCP:Flags=...A...., SrcPort=1075, DstPort=GENA(5000), PayloadLen=0, Seq=3342506104, Ack=1515412577, Win=65535 (scale factor 0x0) = 65535

RPC Bind to the Endpoint Mapper
18 0.000000 {MSRPC:9, TCP:8, IPv4:5} DB2 Client AD DC MSRPC MSRPC:c/o Bind: UUID{12345778-1234-ABCD-EF00-0123456789AB} LSARpc Call=0xD Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
19 0.000000 {MSRPC:9, TCP:8, IPv4:5} AD DC DB2 Client MSRPC MSRPC:c/o Bind Ack: Call=0xD Assoc Grp=0x363A17 Xmit=0x16D0 Recv=0x16D0

End point Map Request to the Application
20 0.000000 {MSRPC:9, TCP:8, IPv4:5} DB2 Client AD DC LSAT LSAT:LsarLookupNames4 Request, *Encrypted*
21 0.000000 {MSRPC:9, TCP:8, IPv4:5} AD DC DC DB Client LSAT LSAT:LsarLookupNames4 Response, *Encrypted*

After these frames only i see that the DB Client connecting to DB Server

22 0.000000 Admin.exe {TCP:11, IPv4:10} DB2 Client DB2 Server TCP TCP:Flags=......S., SrcPort=1076, DstPort=50000, PayloadLen=0, Seq=2538123636, Ack=0, Win=65535 ( Negotiating scale factor 0x1 ) = 65535


The important thing i noted was that our DC are coded to allow RPC Communication on Port 50000 -50200, and for some reason i see that the AD DC is responding to the client that its RPC is listening on port 5000, since the firewall does not allow 5000 it might be casuing the delay before it can establish the a direct communication with the DB2 Server.

What do you guys think?

Any thought would be much appreciated.



"Mel K." <Mel.K@nowhere.com> wrote in message news:edc4ylK7JHA.3860@TK2MSFTNGP05.phx.gbl...
> This is worth a shot: Is the DB2 app dependant on NetBIOS/WINS? If so, make
> sure it has a proper entry and that your WINS settings are correct on the
> WINS server and on the clients (if DHCP, then check DHCP settings also). If
> you don't have WINS, put an entry for the DB2 server in the client's LMHOST.
>
> --
> Regards,
>
> Mel K.
> MCSA: M
> "Kerry" <Phanindra@live.com> wrote in message
> news:ezfy%23LK7JHA.3304@TK2MSFTNGP06.phx.gbl...
> Hi,
> We are seeing a strange problem with one of DB2 Application. The DB2 server
> runs on an AIV Machine and the DB2 clients run in XP Machines. When the XP
> machines are part of a workgroup, the DB2 client works just fine i.e. when
> the user clicks on the application the applictaion credentials windows pops
> up within 2 seconds, however when the same client is joined to the domain,
> it takes 60-100 Seconds for the application authetication wlindows to pop
> up.
>
> I have tried looking at the issue from a DNS Stand point, dont think name
> resolution is a problem here. The DB2 client is configured to Use DB2 Server
> IP and a Specific Port, so its more of an IP Communication.
>
> I have take captures of before and after joining the XP client to the domain
> and noticed that the domain client tries to contact the DC using various
> protocls like TCP (RPC Communication), MSRPC, LSAT. After LSAT packets i see
> that the client connect to the application server. I am thinking if any of
> the domain policies are contributing to the delay. (Note - These captures
> are talen after the login process is completed).
>
> If it was a IP communication between DB2 client and server, i should have
> seen packets directly going to the DB2 Client to the DB2 application server
> and not from the the client to the DC.
>
> I wanted to know what needs to be done to fix this delay...does creating an
> SPN for the DB2 Server help? The DB2 authetication not integrated with AD
> and is not an option.
>
> Any ideas would greatly help.
>
>

My Bad the RPC Ports are indeed set to 5000-5200, so what we see in the frames is expected, however what i dont understand is why would a client contact the DC when an application is being accessed? and why is the handshake happening twice?
"Kerry" <Phanindra@live.com> wrote in message news:OgHZBKk7JHA.1196@TK2MSFTNGP03.phx.gbl...
I do not see any netbios sessions at all in the network capture. When in workgroup, the moment i click on the application its a straight TCP Connection from DB2 Client Src Port 1039 to DB2 Server on Dest Port 50000 (This port is hard coded in the client side).

When the same machine joins to the domain, the moment i click the application, it sends some RPC Packets to the DC and then i see some LSAT frames. I saw these frames and kind of think this is where the issue may be:

First time 3-way Handshake
8 0.000000 {TCP:6, IPv4:5} DB2 Client AD DC TCP TCP:Flags=......S., SrcPort=1074, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=2880073679, Ack=0, Win=65535 ( ) = 65535
9 0.000000 {TCP:6, IPv4:5} AD DC DB2 Client TCP TCP:Flags=...A..S., SrcPort=DCE endpoint resolution(135), DstPort=1074, PayloadLen=0, Seq=2774228518, Ack=2880073680, Win=16384 ( Scale factor not supported ) = 16384
10 0.000000 {TCP:6, IPv4:5} DB2 Client AD DC TCP TCP:Flags=...A...., SrcPort=1074, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=2880073680, Ack=2774228519, Win=65535 (scale factor 0x0) = 65535

RPC Bind to the Endpoint Mapper
11 0.000000 {MSRPC:7, TCP:6, IPv4:5} DB2 Client AD DC MSRPC MSRPC:c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT Call=0xD Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
12 0.000000 {MSRPC:7, TCP:6, IPv4:5} AD DC DB2 Client MSRPC MSRPC:c/o Bind Ack: Call=0xD Assoc Grp=0x2481B8 Xmit=0x16D0 Recv=0x16D0

End point Map Request to the Application
13 0.000000 {MSRPC:7, TCP:6, IPv4:5} DB2 Client AD DC EPM EPM:Request: ept_map:
14 0.000000 {MSRPC:7, TCP:6, IPv4:5} AD DC DB2 Client EPM EPM:Response: ept_map:


Second time 3-way Handshake

15 0.000000 {TCP:8, IPv4:5} DB2 Client AD DC TCP TCP:Flags=......S., SrcPort=1075, DstPort=GENA(5000), PayloadLen=0, Seq=3342506103, Ack=0, Win=65535 ( ) = 65535
16 0.000000 {TCP:8, IPv4:5} AD DC DB2 Client TCP TCP:Flags=...A..S., SrcPort=GENA(5000), DstPort=1075, PayloadLen=0, Seq=1515412576, Ack=3342506104, Win=16384 ( Scale factor not supported ) = 16384
17 0.000000 {TCP:8, IPv4:5} DB2 Client AD DC TCP TCP:Flags=...A...., SrcPort=1075, DstPort=GENA(5000), PayloadLen=0, Seq=3342506104, Ack=1515412577, Win=65535 (scale factor 0x0) = 65535

RPC Bind to the Endpoint Mapper
18 0.000000 {MSRPC:9, TCP:8, IPv4:5} DB2 Client AD DC MSRPC MSRPC:c/o Bind: UUID{12345778-1234-ABCD-EF00-0123456789AB} LSARpc Call=0xD Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
19 0.000000 {MSRPC:9, TCP:8, IPv4:5} AD DC DB2 Client MSRPC MSRPC:c/o Bind Ack: Call=0xD Assoc Grp=0x363A17 Xmit=0x16D0 Recv=0x16D0

End point Map Request to the Application
20 0.000000 {MSRPC:9, TCP:8, IPv4:5} DB2 Client AD DC LSAT LSAT:LsarLookupNames4 Request, *Encrypted*
21 0.000000 {MSRPC:9, TCP:8, IPv4:5} AD DC DC DB Client LSAT LSAT:LsarLookupNames4 Response, *Encrypted*

After these frames only i see that the DB Client connecting to DB Server

22 0.000000 Admin.exe {TCP:11, IPv4:10} DB2 Client DB2 Server TCP TCP:Flags=......S., SrcPort=1076, DstPort=50000, PayloadLen=0, Seq=2538123636, Ack=0, Win=65535 ( Negotiating scale factor 0x1 ) = 65535


The important thing i noted was that our DC are coded to allow RPC Communication on Port 50000 -50200, and for some reason i see that the AD DC is responding to the client that its RPC is listening on port 5000, since the firewall does not allow 5000 it might be casuing the delay before it can establish the a direct communication with the DB2 Server.

What do you guys think?

Any thought would be much appreciated.



"Mel K." <Mel.K@nowhere.com> wrote in message news:edc4ylK7JHA.3860@TK2MSFTNGP05.phx.gbl...
> This is worth a shot: Is the DB2 app dependant on NetBIOS/WINS? If so, make
> sure it has a proper entry and that your WINS settings are correct on the
> WINS server and on the clients (if DHCP, then check DHCP settings also). If
> you don't have WINS, put an entry for the DB2 server in the client's LMHOST.
>
> --
> Regards,
>
> Mel K.
> MCSA: M
> "Kerry" <Phanindra@live.com> wrote in message
> news:ezfy%23LK7JHA.3304@TK2MSFTNGP06.phx.gbl...
> Hi,
> We are seeing a strange problem with one of DB2 Application. The DB2 server
> runs on an AIV Machine and the DB2 clients run in XP Machines. When the XP
> machines are part of a workgroup, the DB2 client works just fine i.e. when
> the user clicks on the application the applictaion credentials windows pops
> up within 2 seconds, however when the same client is joined to the domain,
> it takes 60-100 Seconds for the application authetication wlindows to pop
> up.
>
> I have tried looking at the issue from a DNS Stand point, dont think name
> resolution is a problem here. The DB2 client is configured to Use DB2 Server
> IP and a Specific Port, so its more of an IP Communication.
>
> I have take captures of before and after joining the XP client to the domain
> and noticed that the domain client tries to contact the DC using various
> protocls like TCP (RPC Communication), MSRPC, LSAT. After LSAT packets i see
> that the client connect to the application server. I am thinking if any of
> the domain policies are contributing to the delay. (Note - These captures
> are talen after the login process is completed).
>
> If it was a IP communication between DB2 client and server, i should have
> seen packets directly going to the DB2 Client to the DB2 application server
> and not from the the client to the DC.
>
> I wanted to know what needs to be done to fix this delay...does creating an
> SPN for the DB2 Server help? The DB2 authetication not integrated with AD
> and is not an option.
>
> Any ideas would greatly help.
>
>

For some reason it looks to me that when the application is clicked, the DB 2 client is contacting the AD DC for the Auth Windows (see GENA(5000) frames), instead it should go directly to the DB2 server to get the auth window.

What can be done to mitigate this? any help is much appreciated.
"Kerry" <Phanindra@live.com> wrote in message news:OgHZBKk7JHA.1196@TK2MSFTNGP03.phx.gbl...
I do not see any netbios sessions at all in the network capture. When in workgroup, the moment i click on the application its a straight TCP Connection from DB2 Client Src Port 1039 to DB2 Server on Dest Port 50000 (This port is hard coded in the client side).

When the same machine joins to the domain, the moment i click the application, it sends some RPC Packets to the DC and then i see some LSAT frames. I saw these frames and kind of think this is where the issue may be:

First time 3-way Handshake
8 0.000000 {TCP:6, IPv4:5} DB2 Client AD DC TCP TCP:Flags=......S., SrcPort=1074, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=2880073679, Ack=0, Win=65535 ( ) = 65535
9 0.000000 {TCP:6, IPv4:5} AD DC DB2 Client TCP TCP:Flags=...A..S., SrcPort=DCE endpoint resolution(135), DstPort=1074, PayloadLen=0, Seq=2774228518, Ack=2880073680, Win=16384 ( Scale factor not supported ) = 16384
10 0.000000 {TCP:6, IPv4:5} DB2 Client AD DC TCP TCP:Flags=...A...., SrcPort=1074, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=2880073680, Ack=2774228519, Win=65535 (scale factor 0x0) = 65535

RPC Bind to the Endpoint Mapper
11 0.000000 {MSRPC:7, TCP:6, IPv4:5} DB2 Client AD DC MSRPC MSRPC:c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT Call=0xD Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
12 0.000000 {MSRPC:7, TCP:6, IPv4:5} AD DC DB2 Client MSRPC MSRPC:c/o Bind Ack: Call=0xD Assoc Grp=0x2481B8 Xmit=0x16D0 Recv=0x16D0

End point Map Request to the Application
13 0.000000 {MSRPC:7, TCP:6, IPv4:5} DB2 Client AD DC EPM EPM:Request: ept_map:
14 0.000000 {MSRPC:7, TCP:6, IPv4:5} AD DC DB2 Client EPM EPM:Response: ept_map:


Second time 3-way Handshake

15 0.000000 {TCP:8, IPv4:5} DB2 Client AD DC TCP TCP:Flags=......S., SrcPort=1075, DstPort=GENA(5000), PayloadLen=0, Seq=3342506103, Ack=0, Win=65535 ( ) = 65535
16 0.000000 {TCP:8, IPv4:5} AD DC DB2 Client TCP TCP:Flags=...A..S., SrcPort=GENA(5000), DstPort=1075, PayloadLen=0, Seq=1515412576, Ack=3342506104, Win=16384 ( Scale factor not supported ) = 16384
17 0.000000 {TCP:8, IPv4:5} DB2 Client AD DC TCP TCP:Flags=...A...., SrcPort=1075, DstPort=GENA(5000), PayloadLen=0, Seq=3342506104, Ack=1515412577, Win=65535 (scale factor 0x0) = 65535

RPC Bind to the Endpoint Mapper
18 0.000000 {MSRPC:9, TCP:8, IPv4:5} DB2 Client AD DC MSRPC MSRPC:c/o Bind: UUID{12345778-1234-ABCD-EF00-0123456789AB} LSARpc Call=0xD Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
19 0.000000 {MSRPC:9, TCP:8, IPv4:5} AD DC DB2 Client MSRPC MSRPC:c/o Bind Ack: Call=0xD Assoc Grp=0x363A17 Xmit=0x16D0 Recv=0x16D0

End point Map Request to the Application
20 0.000000 {MSRPC:9, TCP:8, IPv4:5} DB2 Client AD DC LSAT LSAT:LsarLookupNames4 Request, *Encrypted*
21 0.000000 {MSRPC:9, TCP:8, IPv4:5} AD DC DC DB Client LSAT LSAT:LsarLookupNames4 Response, *Encrypted*

After these frames only i see that the DB Client connecting to DB Server

22 0.000000 Admin.exe {TCP:11, IPv4:10} DB2 Client DB2 Server TCP TCP:Flags=......S., SrcPort=1076, DstPort=50000, PayloadLen=0, Seq=2538123636, Ack=0, Win=65535 ( Negotiating scale factor 0x1 ) = 65535


The important thing i noted was that our DC are coded to allow RPC Communication on Port 50000 -50200, and for some reason i see that the AD DC is responding to the client that its RPC is listening on port 5000, since the firewall does not allow 5000 it might be casuing the delay before it can establish the a direct communication with the DB2 Server.

What do you guys think?

Any thought would be much appreciated.



"Mel K." <Mel.K@nowhere.com> wrote in message news:edc4ylK7JHA.3860@TK2MSFTNGP05.phx.gbl...
> This is worth a shot: Is the DB2 app dependant on NetBIOS/WINS? If so, make
> sure it has a proper entry and that your WINS settings are correct on the
> WINS server and on the clients (if DHCP, then check DHCP settings also). If
> you don't have WINS, put an entry for the DB2 server in the client's LMHOST.
>
> --
> Regards,
>
> Mel K.
> MCSA: M
> "Kerry" <Phanindra@live.com> wrote in message
> news:ezfy%23LK7JHA.3304@TK2MSFTNGP06.phx.gbl...
> Hi,
> We are seeing a strange problem with one of DB2 Application. The DB2 server
> runs on an AIV Machine and the DB2 clients run in XP Machines. When the XP
> machines are part of a workgroup, the DB2 client works just fine i.e. when
> the user clicks on the application the applictaion credentials windows pops
> up within 2 seconds, however when the same client is joined to the domain,
> it takes 60-100 Seconds for the application authetication wlindows to pop
> up.
>
> I have tried looking at the issue from a DNS Stand point, dont think name
> resolution is a problem here. The DB2 client is configured to Use DB2 Server
> IP and a Specific Port, so its more of an IP Communication.
>
> I have take captures of before and after joining the XP client to the domain
> and noticed that the domain client tries to contact the DC using various
> protocls like TCP (RPC Communication), MSRPC, LSAT. After LSAT packets i see
> that the client connect to the application server. I am thinking if any of
> the domain policies are contributing to the delay. (Note - These captures
> are talen after the login process is completed).
>
> If it was a IP communication between DB2 client and server, i should have
> seen packets directly going to the DB2 Client to the DB2 application server
> and not from the the client to the DC.
>
> I wanted to know what needs to be done to fix this delay...does creating an
> SPN for the DB2 Server help? The DB2 authetication not integrated with AD
> and is not an option.
>
> Any ideas would greatly help.
>
>