New SMS 2003 Primary - <hopefully> easy question... RRS feed

  • Question

  • Howdy folks,

    We just migrated our test/lab SMS 2003 primary from a 2000 server to 2003 server.  SMS is 2003 SP3.  We followed our standard documentation for new primary builds (obviously we dont build new primaries every day) and ALMOST everything is working great.  This primary is a primary directly attached to our production Central server and sees all new collections and advertisements as locked as they should be.  Our lab guys are creating new advertisements and packages directly on the primary which in turn show as unlocked, again as they should.

    Now the issue...

    The two lab users auto-negotiated the client which did find the new primary site code, but only see advertisements that are machine-based and NOT any advertisements to their lab AD/OU collection.  Site transfer settings was done and all security looks fine.

    What should I be looking at as I am starting to go a little cookoo.

    Many thanks for any input!!

    ~Drew W.

    Monday, July 12, 2010 8:06 PM


All replies

  • In the new site, have you run a AD System Group Discovery process? That would be required to get the AD OU information from AD for the systems.

    Then ensure that you can see the OU information in the discovery properties of the appropriate clients.

    Wally Mead
    Monday, July 12, 2010 11:28 PM
  • we have a scheduled task that runs addisc.exe every night.  Is that what you are referring to? (and thank you for the reply)
    Monday, July 12, 2010 11:56 PM
  • o under client discovery, I specified the LDAP path's they should be accessing.
    Monday, July 12, 2010 11:57 PM
  • ok, after more research, we're getting alerts that there are 93k messages in the statmgr inbox locally on the server.  What would keep the box from processing those status messages?
    Tuesday, July 13, 2010 12:22 PM
  • "we have a scheduled task that runs addisc.exe every night" ??  SMS doesn't utilize scheduled tasks of the operating system to function.  Are you perhaps using a 3rd party discovery mechanism?  Like something from systemcentertools.com ?  Or something you built yourself out of the SDK?

    Discovery actions are normally configured from within the console; not via scheduled task (unless, of course, you are using a 3rd party utility--then contact that vendor for help with their software).

    Statmgr inbox isn't the same inbox used for discovery actions; so a backlog in that inbox is not the same issue as the discovery issue; be sure to treat those issues separately.

    Standardize. Simplify. Automate.
    Tuesday, July 13, 2010 1:26 PM
  • Thank you all for your input!

    Everything is working great after implementing this fix... simply FYI.  thanks again!!!!



    Tuesday, July 13, 2010 3:07 PM