Jaybone

I can't recall makes/models off the top of my head, but I've run into many NICs that won't wake up unless WOL is enabled both in BIOS and from within the OS. I'm assuming that there's some kind of firmware flag within the NIC that is OS-manageable, but I've never really researched the why, just the what.

Are you sure you're actually set up to pull that data you're looking for from the clients? Software inventory happens in a couple ways, so if you're looking at reports or tables for Asset Intelligence stuff but don't have AI turned on, you won't see anything. To check Asset Intelligence stuff: Administration workspace Client Settings in the navigation pane Right-click the settings you're using, Properties Hardware Inventory (yeah... I don't know why) Set Classes Check settings for "Installed Executable - Asset Intelligence (SMS_InstalledExecutable)" and "Installed Software- Asset Intelligence (SMS_InstalledSoftware)" and make sure they're set as appropriate for your environment.

In the meantime, assuming Windows endpoints and that you're OK with PSKs being stored in plaintext at some point in the process, it should be scriptable with a package using netsh.

Disclaimer - I'm not sure where CM is looking to find the version of the MSI to compare against, so my methodology might be flawed, here. ...but it seems like either: 1. it's not the checking "DisplayVersion" registry value in the uninstall branch, nor the "ProductVersion" value in the MSI file's Properties table or 2. The MSI file it's checking has the wrong or missing ProductVersion I'm wondering if it just can't find whatever it's looking for, as far as MSI version, and just evaluating true based on finding the product code alone, since all 11.x versions so far have matching product codes. What we've been doing is, in additon to the product code rule, using a second rule with an AND connector that checks the version of %programfiles%\adobe\reader 11.0\reader\acrord32.exe to make sure that the file version is high enough. Assuming CM is using the Windows Installer records, I suppose you might be able to eliminate possibility 2 by: 1. Looking on an affected system under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData for "adobe reader" without the quotes 2. You'll probably come back with a bunch of results, but one of them should have a whole bunch of values, one of which will be LocalPackage 2a. On my test system, I found it in under S-1-5-18\Products\68AB67CA7DA73301B744BA0000000010\InstallProperties since it was installed by CM. 3. Copy the msi file specified in the LocalPackage value to a temp folder somewhere (may not be strictly needed, but I'm reluctant to ever mess with the live ones) 4. Open that copy of the msi with Orca or some other msi editor 5. In the Properties table, what does it have for the ProductVersion value?

Check your PM first, but... You could use some/most or your previous methods, sure. The .wim file captured with imagex can be used in an OSD task sequence. If you're dealing with multiple models of workstations, you might want to/should probably think about skipping driver installation of your master image, and let the task sequence take care of it for you during deployment. Not sure how the copyprofile feature behaves in a config manager scenario, as I've never bothered with it.

You can enable the remote registry service for the endpoints you're interested in via GPO, if that's suitable for your needs. If you want to just do a quck check on a system or two remotely, running 'sc \\targetName start remoteRegistry' should suffice. As Peter said, though - you shouldn't need to do this for CM to be able to check. Enabling remote registry will allow you to connect from elsewhere, e.g. your workstation with the proper credentials, but the CM client itself is local, and shouldn't be effected by remote registry being turned off

Why? Good question. "Because that's the way it's always been," I guess. From what I understand, the network here was kind of a mess when CM was first installed about 8 months before I started. I think the idea was to find out what was out there and not known about at the time. Still a good thing to be doing, in my opinion, but it's not like anyone actually has time to look at or follow up on any of the unknowns, anyway... >>>Do all of these duplicate, inactive objects have the same value and are discovered by Network Discovery?<<< Yep.

Hi, all. Weird thing... Config Manager 2012, SP1. AD discovery and network discovery are both on. We've got a number of computers showing up twice in CM. For each of these, there's one instance that looks all fine and happy with successful deployments, etc; then there's another "bare-bones" kind of version with only a handful of properties actually populated. For the bare-bones copy of these: Some things match the active client, namely - MAC Address; IP Address; subnet; Resource Domain or Workgroup; Name; NETBIOS Name; AD, Agent, CM Assigned, CM Resident sites, Resource type (=System), and Decommissioned (=No) While other stuff differs - Agent Name = "SMS_NETWORK_DISCOVERY" (active client has this along with others) Creation Date is always well after the creation date of the "real" copy Resource ID is way different Resource Names = netbios name and FQDN, where active client only has FQDN here And the rest of the fields are usually empty, but not always. LastLogonTimeStamp is sometimes present - I'm guessing this is a case of the DB updating the field for the wrong instance. E.g. I'm looking at one now where the bare-bones copy has a Last Logon Timestamp of 18 August while the real copy is showing a Last Logon Timestamp back in April, right around the time the bad copy showed up. The real one has a last policy request from less than 10 minutes ago... What am i missing here that's causing these to show up? With only a few dozen, it's not a big deal for me to just go in and get rid of them manually, but I'd rather address the root cause. Pretty sure it's not a case of AD delta discovery+OSD looking for unknowns, which is about all I can google up in regards to duplicates, as these new copies showed up in mostly in July 2014 for systems that were either built from scratch or OSD'd and have been in AD for a year or more.

~~~much time passes~~~ After both messing with packet size settings and redistributing both the x86 and 64 boot images, we haven't run into this again for probably close to four weeks. We also haven't distributed a whole lot of new systems in that time, so I still don't have a definite answer, but it's looking good so far.

Both are distributed. Only the x86 image is referenced by any TS. That's something I didn't consider, though - if the 64 bit image is hosed up, maybe that could cause problems? In SMSPXE.log, the repeated "Looking for bootimage XXX00004" entries are referencing the x86 boot image - the 64bit image is XXX00005.

What version of SEP? How are you exporting the installer from SEPM - single .exe or the mutil-file .msi-based installer? FWIW, we have it working fine on 2012 sp1 (not R2) with 12.1.4 and the .msi. The single exe didn't play nice (I forget exactly what was going on with the failure, and the logs probably aren't around anymore), but using the msi based installer with install flags of SYMREBOOT=ReallySuppress /qn /norestart.

Thanks for the responses, all. Nope, this is 2012, SP1. The ones we see this with most are brand new Dell Optiplex 7010 units, BIOS A16 (latest available). Identical configs on all of them, and some are flawless while others are wonky. Same switchports, same cabling, different results. Clients' network settings are triple+ checked and known good, DNS working well. As far as not contacting wds: it sure looks that way from the client end, but the logs seem to indicate otherwise, with the repeated "Looking for bootimage..." entries in SMSPXE while this is happening. This is what has me so confused. I'll tweak the packet size settings and see if that makes a difference, thanks.

Hi, all. We're currently seeing a strange issue with OSD and new systems. What's happening is that probably 95% or more of new systems have zero problems - PXE boot, pull down a task sequence and all's well. The remainder, though... they'll start the PXE process seemingly fine, but get stuck. "contacting server: w.x.y.z........................................ <imagine two more lines of ... here> Failed to restart TFTP. TFTP download failed. PXE-M0F: Exiting Intel Boot Agent. Selected boot device failed. Press any key to reboot the system." SMSPXE.log shows repeated "Looking for bootimage XXX00004" messages at this point, and will do so until the client is turned off or eventually times out. While this is happening, other systems, both existing and new, can PXE boot into the OSD environment just fine, and use the exact same boot image (which shows up in SMSPXE.log as "Looking for bootimage XXX00004" exactly one time for that system) while they're going through the PXE process. Minutes, hours, or days later, the problematic systems will all of a sudden start behaving normally, and complete the boot process. Googling on this has come up with s number of promising results, but they seem to all be related to people who are having this problem with everything, not just a tiny percentage of systems, and I'm not sure the restarting or reinstalling WDS is the answer, since it seems so random. Anyone have any ideas, or know where to look to nail down what's causing this?