Configuring and Troubleshooting File Access through IAG 2007 – Part 2 of 2

Configuring and Troubleshooting File Access through IAG 2007 – Part 2 of 2

  • Comments 1
  • Likes

1. Introduction

 

Most of the problems that could potentially occur with this feature are usually exposed during implementation. In many situations problems happen because key points were not considered or addressed prior to the implementation. During the troubleshooting phase the most important thing is to know how to gather the right information in order to analyze and identify the root cause. This part of the post will focus on this piece and it is an important one.

 

2. Scenarios

 

For the purpose of this guide, there it will be presenting two problems and the approach for the troubleshooting. Let’s start with the first problem:

 

I’m configuring the File Access, when I click in Domain and then click in Refresh, the right pane shows up blank and the status bar is already showing as Ready.

 

Before even start to troubleshoot this, it is important to find out if you are really capable to browse the Network Neighborhood / Windows Network through Windows Explorer. If you are not, than fix this first before move on. A good start to address issues with computer browser in the OS side is by following the KB 188305.

 

I fixed this part, now I’m able to browse using Windows Explorer and also through IAG. However, when I select a computer, click apply, select share and click in refresh it says: No shares in this server. But it does have because I can access directly from start / run and type the UNC path for that share.

 

The question remains: are you able to access this share using Windows Explorer? If not then you need to fix this first before move on to IAG. Simply access directly the UNC path just proves that you have the path (no roadblock in the middle) and the authorization to access, but the browser list it is different. This is the reason why you need to address the browsing side first.

What you can also do in order to get more information about the error is by enabling the IAG File Access tracing. To do that, follow the steps below:

 

1) Open the folder \Whale-Com\e-Gap\von\InternalSite\inc\ and edit the trace.inc file.

2) Change the value trace_on to true (trace_on=true) and save the file.

3) Open the folder \Whale-Com\e-Gap\common\conf\ and edit the trace.ini file. Go to the bottom of the file and add the line below:

 

[Trace\ShareAccess]

*=xheavy

 

Note: hit ENTER after *=xheavy to commit.

 

4) Save the file and reproduce the problem.

5) The log files will be located at \Whale-Com\e-Gap\logs and the file name will be following the standard below:

 

SERVERNAME.ShareAccess.default.DATE.TIME.log

 

If you want to go beyond, what you can do is also enable Netmon in the internal interface of IAG and starts the capture while trying to configure the resource.

 

Ok I got the file, now what should I do?

 

This file is really verbose and has lots of information that can help to identify the root cause for the problem. Let’s take a look in the main portion of this log file:

 

Here we start validating the user:

** 19.06.08 16:23:27.161 SHAREACCESS:GENERAL T3860

SetUserData start: domain=[contoso], user=[administrator]

* at line 129, file "src/ShareEnum.cpp".

 

The validation is done successfully:

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3860

SetUserData end: domain=[contoso], user=[administrator] - SUCCESS

* at line 143, file "src/ShareEnum.cpp".

 

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: path [servers/server] type [2]

* at line 458, file "src/Settings.cpp".

 

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: after reading the xml include all 1

* at line 503, file "src/Settings.cpp".

 

Number of share that were previously selected:

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: num of shares [2]

* at line 513, file "src/Settings.cpp".

 

The share in the DALLAS computer is marked as it needs to show the shared folders:

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: the share [CONTOSO\DALLAS] is marked [1] have the provider [MS]

* at line 538, file "src/Settings.cpp".

 

No need to show the shared folders in the IBIZA computer:

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: the share [CONTOSO\IBIZA] is marked [0] have the provider [MS]

* at line 538, file "src/Settings.cpp".

 

 

Starts to enumerate the shares:

** 19.06.08 16:23:27.181 SHAREACCESS:GENERAL T3860

AdmEnumerateShares start

* at line 92, file "src/ShareEnum.cpp".

 

Failed to enumerate the shares:

** 19.06.08 16:28:10.138 SHAREACCESS:GENERAL T3860

AdmEnumerateShares end - FAIL

* at line 118, file "src/ShareEnum.cpp".

 

Ok, we failed to enumerate the shares, now we need an extra help from netmon trace. Let’s see what we have it:

 

In the beginning of the trace we have the server DALLAS announcing itself as the master browser:

DALLAS      10.255.255.255    BROWSER     BROWSER:Host Announcement, ServerName = DALLAS

 

Later one, the handshake…

IBIZA       DALLAS      TCP   TCP:Flags=......S., SrcPort=2395, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2961358224, Ack=0, Win=65535 (scale factor 0) = 65535

 

DALLAS      IBIZA       TCP   TCP:Flags=...A..S., SrcPort=NETBIOS Session Service(139), DstPort=2395, PayloadLen=0, Seq=2095277429, Ack=2961358225, Win=16384 (scale factor 0) = 16384

 

IBIZA       DALLAS      TCP   TCP:Flags=...A...., SrcPort=2395, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2961358225, Ack=2095277430, Win=65535 (scale factor 0) = 65535

 

.. and the IAG server trying to retrieve information directly from DALLAS but it doesn’t receive and answer:

IBIZA       DALLAS      NbtSS NbtSS:SESSION REQUEST, Length =68

 

Then IAG Server starts to broadcast trying to find someone that has list:

IBIZA       10.255.255.255    BROWSER     BROWSER:Get Backup List Request

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1B> Domain Master Browser

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1B> Domain Master Browser

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1B> Domain Master Browser

IBIZA       10.255.255.255    BROWSER     BROWSER:Get Backup List Request

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1B> Domain Master Browser

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1B> Domain Master Browser

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1B> Domain Master Browser

IBIZA       10.255.255.255    BROWSER     BROWSER:Get Backup List Request

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1B> Domain Master Browser

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1B> Domain Master Browser

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1B> Domain Master Browser

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1E> Browser Service Elections

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1E> Browser Service Elections

IBIZA       10.255.255.255    NbtNs NbtNs:Query Request for CONTOSO  <0x1E> Browser Service Elections

 

For this particular problem, the issue was with the DALLAS server: customer installed a personal firewall on it and it was blocking the UDP traffic.

 

3. Conclusion

 

We can conclude it here that this is more likely a networking issue rather than an IAG issue. Therefore the test of accessing the share directly through UNC cannot be considered conclusive. You really need to focus on the Windows Browsing through Windows Explorer.

 

 

Author

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – TX

 

Technical Reviewer

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – WA

 

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment