I believe that kb830063 is simply wrong for an SBS, quite possibly just
wrong.

You should NEVER have Nbt enabled on RRAS adapters on an SBS. More
specifically, you CANNOT multihome Netbios on a DC...peroid. It is contrary
to the design of Microsoft Networking requirements for Netbiod...period.
There's no hotfix about this, this is MS Networking law.

You must always disable Netbios on all secondary adapters on a DC running
RRAS because otherwise, the DC attempts to become Segment Master Browser on
more than one network segment, listening and reporting to itself only what
it hears on one segment or the other, but not both. That's what leads to
browser failures. The exception to this behavior is that if the RRAS adapter
is not routing, rather is a PPP connection for a single client being given
Ips on the same subnet as the LAN, then the DC involved will treat both the
LAN and the PPP link as a single segment.

The correct solution to the problem described is to enable WINS on the DC
(in this case the SBS) and provide the WINS server settings in the RRAS DHCP
configuration, as well as DNS. In this way, RRAS clients will be able to
resolve network (LAN) browsing correctly. XP/W2K clients will pull from DNS,
legacy clients will query WINS, the DC will ignore Master Browser role for
the RRAS link on a different subnet or will include PPP clients accordingly.

...related to this....

Richard, I scrolled down in the NG to read several of the last posts you
made related to VPN connections and IP assignments. I can see that you have
been working on this for some time and with some frustrations. I realize
that you are not likely to want to "break" the solution you have working
just because I have stated above that it is wrong.

When configuring remote clients to connect via RRAS (either dialup or VPN),
you can assign static IPs. It's possible to assign them either in the same
subnet or on a different subnet. But here is where the discussion above goes
to a new level of complexity.

What I recommend as your best practice is to follow the directions I gave at
the top, and then continue with the following.

I recommend that when you want to configure static IPs for RRAS connected
clients, you should use a different subnet. Do this by creating an
additional DHCP Scope for the new subnet. Then configure all or part of that
range to the RRAS assigned by DHCP. Enable RRAS for routing. Finally, assign
static IPs for the user accounts you intend to have connect via RRAS in the
(AD Users and Computers) user account properties for Dialup Networking in
the section for "assign a static IP". Finally, in the DHCP scope for the LAN
that supports all the rest of your workstations, add the setting to "default
gateway" and point that at the LAN IP of the SBS (assuming that your SBS is
running ISA and is supporting web traffic on a second NIC). You will need to
decide if you want ISA to filter this subnet, or not. If you add this new
subnet to the LAT, it will be treated as a trusted subnet, but the other
option is to setup filters to pass only the traffic you want from RRAS
connections.

If you use a router on the LAN to reach the web, the alternative is to set a
static route on the router to point at the SBS as gateway for the subnet you
just created, or create a static route on each workstation/server in the LAN
pointing at the SBS LAN IP as the gateway for the subnet you are giving to
the RRAS clients.

With the above configuration, your users always get a static IP, and their
connection is routed into the LAN. With the SBS as either the default route
gateway out of the LAN, or as the gateway for all workstations looking for
the new subnet these RRAS users will appear on, you will have IP routing
work correctly for all users. The above information at that very top will
provide correct browsing support, and using WINS and DNS will enable all
subnets to see each other in Network Neighborhood as expected. This is how
MS Networking is designed to work with a scenario of a physically or
logically multihomed DC running name resolution for MS Networking. This
solution works in all cases.

In addition, you have an added benefit now. By putting the RRAS connections
on a different subnet, you now have the option to configure specific rules
in ISA to filter the RRAS connections. You can configure this so that you
only allow the protocols you want for specific connections, or you can leave
it wide open.

Further benefits.....if you have users who have laptops they use in the
office or out, they can now have a particular IP they are on when in the
LAN, and a different one when they are on RRAS. This can allow for
additional configuration options, but more importantly, it assures that the
configuration can match the needs of the condition they connect by. For home
based computers, the use of the static IP allows for mapping printers to be
reached via TS or RDP connections using the static IP as the port.