Jump to content


wanderer

Established Members
  • Posts

    30
  • Joined

  • Last visited

Everything posted by wanderer

  1. Hi, First, thanks for your excellent guides, the only way I got 2007 working. Just looking for some advice. We are using the AD site as the boundary for our existing 2007 SCCM. When I install 2012 in the same AD is it safe to add our new server in the "Delegate Control" bit of the Systems Management OU container - so both servers would have control? I'd use a different site name for the new server but I'm worried about one of our 2007 clients picking up the wrong site code. Our clients are in the build and we use Heartbeat discovery. I was thinking for 2012 making the boundary a test IP address range until I've migrated everything across. Or would it be safe to use the AD site here too? I don't know to what extent 2007 clients could see a 2012 server and vice versa. Has anyone already done this? Cheers, Stephen
  2. Hi, I'm using SCCM 2007 R3 on Server 2008 sp2 (32). I'm having problems with PCs that are showing up in All Systems as Client=No. It seems to be related to the way they are discovered. If I have a PC that shows as Client = Yes and then I delete it from SCCM (but leave it in AD), if I run System Discovery or let Delta Discovery take place (without rebuilding the PC) the PC shows up again with Client = 0. Agent Name(0) is SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT (Time is 13:00.01) and Agent Name (1) is SMS_AD_SYSTEM_DISCOVERY_AGENT (Time is 13:30.01). I'm confused because from the documentation I thought that System Group discovery only added AD info to PCs that had already been found by another method. Yet here Agent 0 is dated earlier? However, if the PC is discovered by Heartbeat then the Client=Yes, for example Agent Name (0) is Heartbeat Discovery (time 13:44.09) and Agent Name(1) is MP_ClientRegistration (time 09:54:42). I suspect I'm missing something obvious here, but I don't understand why System Discovery can't find the client but Heartbeat can. Adding to my confusion is the fact that when a PC is found by System Discovery, even though in All Systems Client = No, in a short time all the apps show in RAP and work OK. I would greatly appreciate if you could offer any suggestions, Thanks in advance, Stephen
  3. Hi, I have SCCM 2007 installed on Server 2008 sp2. I want to check if another admin has already created an app for Winedit for example. If the app exists in the top level folder, if I fill in the "Look For" field with "Wine" then click on Find it returns the app no problem. In this case another admin had already created the app in a Folder under the root of Packages called "Scientific Text Editors" - however this wasn't found, it does work if I select this sub-folder and then do a "Look For". Is there some way to get "Look For" to search sub-folders as well? Do you have any ideas about how I can avoid duplication? So far all I can think of is to search the Distribution Point server but I was hoping there is a better way around this. Thanks Stephen
  4. I am currently testing SCCM 2007 on Server 2008 sp2 with Windows 7. When we rebuild a PC it comes out of Sysprep, renames itself to the same name as before, reboots and then joins the domain with the correct name. This all works OK - not being done by SCCM. I have the Collection set to update membership every hour and I have the AD System Discovery task set to run every 5 minutes for testing. I also have a task to delete the obsolete data related to the old PC, this also works OK. The problem is that the rebuilt PC does not receive any advertisements until I do an Action/Refresh on the Console; even if I leave it for 24 hours or more. Once I've done a Refresh with the correct collection the PC receives its advertisements in a timely manner. I don't understand why doing a "Update Collection Membership" does not include "Refresh", perhaps someone who understands this can explain. Is there some way of scripting or forcing a "Refresh"? Thanks for your help, Wanderer
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.