locked
SMS 2003 SP3 does not recognize that Advanced Client is installed? RRS feed

  • Question

  • The one thing I don't like about SMS/SCCM is having to 'wade through' tons of logs to find anything useful regarding why something does or 'does not' happen, such as proper discovery/communication with an agent/client on a workstation. We are on SMS 2003 SP3 and we will soon go to SCCM but, due to timing, we need to stay on SMS for a few more weeks.

    Problem is that SMS does not seem to be recognizing that the client is installed on some particular systems (yes, Advanced Client only, we don't have any of the old legacy stuff).

    Then, in some cases, even when something is 'advertised' and shows up on 'Run Advertised Programs' and all the settings and doo-hickeys are configured for 'mandatory' and all of that, the advertisement doesn't run. Now, I did check "copy / download" the software and so that shouldn't really make a difference; yes, security is a-okay - made sure I added the SMS MP/Site server machine as an admin for these particular workstations.

    We are on Windows Server 2003 Standard Edition, Service Pack 2 and, apparently we are SMS 2003 SP3, because Windows Update finds NO udpates for the SMS software.

    And yes, I know that, sometimes uninstall/reinstall of the SMS client fixes things, but it shouldn't be necessary - just DISCOVER the system and then see that the client is there! Thoughts appreciated. Thanks.

    So, any ideas?

    Tuesday, January 25, 2011 5:19 PM

Answers

  • and all the settings and doo-hickeys

    Another curiousity - there seems to be a SEVERE lack of documentation regarding a small item called "Server Share" - where

    Bottom line: we want "LIGHT" shares (preferably XP-based) at the remote sites, since we do not have a server at each remote site.

    Is that possible, feasible? Otherwise, what is recommended? Also, small 'pipes' to each remote site - thus we want to be able to copy the Office 2010 pkg to the shares at each satellite location, and then have the workstations install via those local DPs - vs. across the WAN, which is not just impractical, but virtually impossible.

    It seems in Microsoft's infinite wisdom, they did not realize that not everyone wants to have a full-blown 'server' at small satellite sites, just to act as a DP. OR, they saw this as an opportunity to squeeze out more licensing + support revenue, by requiring users to install 'Server' vs. 'Workstation.'

    First of all, if all your doo-hickeys are right, did you check your thinga-ma-jiggers? (sorry, couldn't resists)

    IMHO the docs around SMS 2003 were lacking in almost all perscetives. SCCM changed all of that. As you can see there's a ton of info about server share DP's in SCCM http://tinyurl.com/servershares

    SCCM gices you the ability to use a workstation as a branch distribution point exactly as you desire. http://tinyurl.com/branchDP

    Since secondary sites are free and have been since SMS 2003 I don't think this is a conspiracy to get us to purchase more licenses.

    While I understand I haven't been helpful at all with your current problem I hope some of the links I provided will help you make the decision to move off SMS 2003 and onto SCCM quicker. I think you'll find it well worth it.

     


    John Marcum | http://myitforum.com/cs2/blogs/jmarcum/|
    • Marked as answer by titanyoda Wednesday, February 16, 2011 4:01 PM
    Wednesday, January 26, 2011 12:58 PM

All replies

  • If the program appears in Run Advertised Programs, and it is mandatory, then...

    Confirm the mandatory start time has actually passed.  I've been tripped up by that before, accidentally picking 2012 instead of 2011 for example. 

    If the mandatory start time has passed, I'm sorry, but you are going to have to buckle down and learn to love log files.  The log files will tell you everything.  But yet, there are a lot. 

    for an advertisement, I would look at execmgr.log, and (possibly) cas.log, clientlocation.log.

    Last but certainly not least... Perhaps the program "ran" successfully according to ConfigMgr.  But the program was simply a batch file (I'm just making this up, as an example).  and the batch file per se ran... but the guts inside of it didn't actually deliver the payload. 

    You have to think of SMS/Configmgr (in this case) as the UPS van.  UPS found the address (the target computer) and dropped off the box at the front door.  Whether or not the packager packed the contents so that it's not broken upon delivery... that's up to the packager.


    Standardize. Simplify. Automate.
    Tuesday, January 25, 2011 6:42 PM
  • Thanks. I'm sure you're right. It is mandatory, and the time has passed.

    One case, I did a complete uninstall, reinstall, rediscovery, etc., and yet still shows on the SMS Admin console "no client installed" and yet, the sms site server log file says "Detetected Advanced Client on [target-box]" (where 'target-box' is the name of the cient computer); so, clearly, SMS "knows" the Advanced Client is on there, but the console is NOT updating the status to show that it is installed. And YES, I did the requisite manual 'repair' (in Components tab), and "Initiate" on all items in the other tab, and click "Discover site" and it says, "Yes, same site discovered as the one you have listed..." - so.... been there, done ALL of that, and stil on some systems, the client is NOT showing as being installed.

    Special case: these systems had SMS advanced client, then they were re-imaged with NO SMS client; thus the console of SMS still had them listed as HAVING the SMS client installed - so, any thoughts on that? I"m thinking delete the record in SMS, do the recommended 'cleanup / uninstall' - reboot - then do a re-discovery, then push the client to the workstations in question BUT, as far as I know, I've already done that (over and over and over).

    Another curiousity - there seems to be a SEVERE lack of documentation regarding a small item called "Server Share" - where you can setup a Dist Point on a share - we are NOT wanting to install Windows Server at 20+ locations JUST to have an SMS dist point; so, is it possible to have the DP setup as a "Server Share" on an XP system? Documention for SMS shows it is 'unsupported' but, so far, I have set it up (with IIS installed on the XP system, apparently as a requirement), and SMS does, indeed copy the software pkg from the SMS Site Server to the XP system's share! But, it seems to halt at that point.

    Bottom line: we want "LIGHT" shares (preferably XP-based) at the remote sites, since we do not have a server at each remote site.

    Is that possible, feasible? Otherwise, what is recommended? Also, small 'pipes' to each remote site - thus we want to be able to copy the Office 2010 pkg to the shares at each satellite location, and then have the workstations install via those local DPs - vs. across the WAN, which is not just impractical, but virtually impossible.

    It seems in Microsoft's infinite wisdom, they did not realize that not everyone wants to have a full-blown 'server' at small satellite sites, just to act as a DP. OR, they saw this as an opportunity to squeeze out more licensing + support revenue, by requiring users to install 'Server' vs. 'Workstation.'

    Fallback is to have a GPO/Startup/Login script that installs the pkg, after we manually copy it to all 20+ remote "XP shares."

    All thougths & comments welcome.

     

     

    Tuesday, January 25, 2011 9:06 PM
  • and all the settings and doo-hickeys

    Another curiousity - there seems to be a SEVERE lack of documentation regarding a small item called "Server Share" - where

    Bottom line: we want "LIGHT" shares (preferably XP-based) at the remote sites, since we do not have a server at each remote site.

    Is that possible, feasible? Otherwise, what is recommended? Also, small 'pipes' to each remote site - thus we want to be able to copy the Office 2010 pkg to the shares at each satellite location, and then have the workstations install via those local DPs - vs. across the WAN, which is not just impractical, but virtually impossible.

    It seems in Microsoft's infinite wisdom, they did not realize that not everyone wants to have a full-blown 'server' at small satellite sites, just to act as a DP. OR, they saw this as an opportunity to squeeze out more licensing + support revenue, by requiring users to install 'Server' vs. 'Workstation.'

    First of all, if all your doo-hickeys are right, did you check your thinga-ma-jiggers? (sorry, couldn't resists)

    IMHO the docs around SMS 2003 were lacking in almost all perscetives. SCCM changed all of that. As you can see there's a ton of info about server share DP's in SCCM http://tinyurl.com/servershares

    SCCM gices you the ability to use a workstation as a branch distribution point exactly as you desire. http://tinyurl.com/branchDP

    Since secondary sites are free and have been since SMS 2003 I don't think this is a conspiracy to get us to purchase more licenses.

    While I understand I haven't been helpful at all with your current problem I hope some of the links I provided will help you make the decision to move off SMS 2003 and onto SCCM quicker. I think you'll find it well worth it.

     


    John Marcum | http://myitforum.com/cs2/blogs/jmarcum/|
    • Marked as answer by titanyoda Wednesday, February 16, 2011 4:01 PM
    Wednesday, January 26, 2011 12:58 PM
  • Oh, you've been more than helpful. I prefer SCCM; managed it at my 2 previous jobs and... I don't 'dislike' SMS, but SCCM is a vast improvement over it.

    I will have to follow the recommended 'upgrade path' - i.e., backup all the SMS thinga-ma-jiggers (LOL), plop down SCCM and/or upgrade (whatever is recommended); and then re-load/restore the thinga-ma-jiggers.

    Another thought is just "SCCM clean install" - BUT, can anyone tell me the [additional] things I may have to remove from AD? In other words, I know there are several 'hooks' into AD and so forth, and if I just uninstall and/or remove the existing SMS site server and start with SCCM from scratch - is that a viable strategy (since currently we have mininal packages and so forth in SMS)?

    I'm also very okay with upgrading but, as I said, my understanding is that you have to do a backup, then upgrade, then restore from the backup, in order to actually perform upgrade from SMS to SCCM. Any clarification would be greatly apprciated. Thanks again for all the help. Either way, I don't want to have any left-over and/or 'bad' items from SMS-land that might still 'burp' after the upgrade to SCCM; i.e., if SMS wasn't fully and masterfully configured to start with, I might just be putting a band-aid on a compound fracture.

    Thoughts? Advice? Advil?

    Wednesday, January 26, 2011 1:21 PM