SMS Network Discovery/AD System Discovery

[mnt25]

The problem: Network Discovery has been configured to locate IP subnets outside the AD forest and in DMZ firewall areas. However, even after listing these IP subnets successively, the only resources that are discovered are those located in the IP subnet where the SMS Site exist. I'm not clear on the exact requirements to get to this to work. I've been told that specific ports including UDP 137-139 and HTTP/RPC would need to be configured for the eventual installation.
The advanced client is being utilized in the SMS design and I am aware that it will query AD Site in AD for the local forest specified. But now resources outside the current forest (with no trust between the forest) will be needed. I am trying to determine the requirements to get network discovery to pick up resources in these 'locked down' areas and then i would like to install the advanced client only on selected servers using collections. Any feedback would be greatly appreciated.

Kind Regards,
Mattti

 

[Jpoandl]

When using the Advanced client on NON-DOMAIN computers, you must use WINS.

I know, this can be problematic...especially when you want to get away from WINS but it is the only solution I was able to find.

You only need ONE WINS entry to be available to all NON-DOMAIN computers. So this will minimize the effort. Please read below:

SMS 2003 WINS Dependency for Client Outside of Active Directory Domain


Background:

I've been in the process of building my SMS 2003 lab site here in America. My setup is fairly basic: One Windows 2003 Server running 3 Virtual Servers- to act as SMS clients.

My lab: SMS 2003 exists in a Windows 2003 Active Directory forest in Native mode. I have been successful in installing the SMS Advanced Client on all systems that are part of the domain. However, to simulate the environment in the US, I choose to create a few clients that are not part of the domain (i.e. Workgroup clients).

What I discovered is that for clients that are NOT part of the AD domain structure, (it seems) that the Advanced Client would not install. I spent a little bit of time trying to get the SMS Advanced client installed on these Workgroup machines. Finally, I noticed a log file called ClientLocation.log that indicated that the client could not find the SLP and therefore, would not be able to report back to the SMS site. Furthermore, the log file indicated that WINS was needed to locate the SMS site.

I did some further research on this issue and found that for clients that are NOT part of AD, WINS is needed for the Advanced Client installation and reporting. Please let me know if you have found this to be untrue. I think this might be important issue for some environments.

I think the reason that an Advanced Client NOT part of the AD domain needs WINS is because it cannot query AD for locating the SLP.

After I installed WINS, my problem was solved. Although, I did have to MANUALLY create an SLP record in my WINS database.



Here is more information about this issue:



Advanced Client key points (See point 5) From:

http://www.myitforum.com/articles/8/view.asp?id=6685

1. All new design

2. Only runs on Win2k or above

3. Recommended client for all Win2k and above systems

4. Uses Local System Account and Computer Account for client functions.

5. Uses Wins or AD to locate SLP to find MP to install client.

6. Uses Management Points for most client communication.

7. Uses administrator defined Policies retrieved from MP to dictate client settings

8. Cannot be assigned to secondary sites(INTERESTING)

9. Can download all application source files and then install software locally instead of over the network

10. Can utilize Roaming functionality

11. All client agents are installed by default (just not enabled) (except for remote control)

12. Can install entire advanced client on a system without assigning it to a site (helpful for prestaging clients)

13. Client install is an MSI package.

14. Can utilize Protected DPs and roaming to locate a local DP

15. Can utilize BITS technology for most client traffic.



Instructions to Create the Manually WINS entry for SLP:

http://www.myitforum.com/articles/8/view.asp?id=6765

Installing SMS Locator Point in Windows NT 4 Environment


By: Britt Baubie
Posted On: 1/20/2004

If you are currently in the middle of a deployment of SMS 2003 and have not migrated from a Windows NT 4 domain, you will find the documentation quite vague on how to enter an SMS locator point into WINS for NT4. This is absolutely crucial or your advanced clients will not find the SMS server.

After searching several resources, I found a tool from the NT4 resource kit called Winscl. Winscl is run from the command line and allows you to read, scavenge and enter items into the WINS database.

The following is a step-by-step procedure for entering the Locator Point into WINS:

From a command prompt, change directory to where the executable resides. Enter winscl.exe

1. Type 1 – This is the entry to connect by TCP/IP
2. Enter IP Address of WINS server x.x.x.x
3. Type RN – Register the Name
4. Type SMS_SLP – Registers the entry as SMS Server Locator Point
5. Type 1 – Adds 16th character to record
6. Type a– Makes a the 16th character
7. Type 1 – Scope
8. Type 0 – Unique Record
9. Enter IP of SMS Server x.x.x.x
10. Type 0 -- (P-Node)

It’s quite simple and you will notice that the record shows up in your WINS database. If you replicate to several servers, you only need to accomplish this task once. The record will look something like this:

SMS_SLP[1Ah] x.x.x.x



Joseph L. Poandl
MCSE 2003

If your company is in need of experts to examine technical problems/solutions, please check out

http://www.NJCOMPUTERNETWORKS.com

(Sales@njcomputernetworks.com)