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.
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:
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:
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 
* at line 458, file "src/Settings.cpp".
CSettings::GetObjects: after reading the xml include all 1
* at line 503, file "src/Settings.cpp".
Number of share that were previously selected:
CSettings::GetObjects: num of shares 
* at line 513, file "src/Settings.cpp".
The share in the DALLAS computer is marked as it needs to show the shared folders:
CSettings::GetObjects: the share [CONTOSO\DALLAS] is marked  have the provider [MS]
* at line 538, file "src/Settings.cpp".
No need to show the shared folders in the IBIZA computer:
CSettings::GetObjects: the share [CONTOSO\IBIZA] is marked  have the provider [MS]
Starts to enumerate the shares:
** 19.06.08 16:23:27.181 SHAREACCESS:GENERAL T3860
* 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 <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.
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.
Security Support Engineer – ISA/IAG Team
Microsoft – TX
Security Support Engineer – IAG Team
Microsoft – WA
PingBack from http://blogs.isaserver.org/shinder/2008/10/14/iag-2007-remote-file-access/