hhancock

Removing the device from the database and performing a full discovery seemed to have worked. The device was rediscovered fine and the client was installed. The only thing now is to figure out why it's not showing up in the correct device collection. I have device collections based on an OU called Workstations within another OU for each geography. For example, ATL > Workstations, BHM > Workstations, etc. I think that it might not be showing up in the device collection because the schedule was set to run once every 7 days. I've since changed the rule for the device collection to once per hour. We'll see if it shows up. The device does show up correctly in the All Systems collection and is showing in the correct Active Directory Site.

Hmm, the computer is showing in the log now and is showing in the All Systems device collection, however it's showing as inactive. I've since removed the device from the database and running another full discovery.

It's in the OU. My WDS server adds the computer to the domain and moves it to the proper OU. I've confirmed that the computer is in the correct OU.

It's actually now moved from Critical to Warning. The warnings appear to be certificate related.

I am not 100% sure what's going on but if a computer is currently in AD and I use WDS to reinstall the image the computer name stays the same. This is not what I want at all. Usually, the computer is being reimaged and given to a new employee and we are using the USERNAMELT00 standard. Is there anyway to force WDS to create a new computer name every time I PXE boot? For the record, I do have the Client Naming Policy set to %61Username%02# in WDS. Any help would be greatly appreciated.

I have a device that's been in Active Directory for about two weeks but doesn't show in SCCM. Other devices more recently added to AD have been discovered and have successfully installed the SCCM client. How can I troubleshoot a single device? I am using Active Directory System Discovery and have run a full discovery with no luck.

I recently noticed that the SMS_MP_CONTROL_MANAGER component is in a critical state. With that said, I don't see any errors when checking the messages, only warnings. What can I do to get this component back into an OK status?

I can't seem to get the WDSClientUnattend.xml file to work properly. I am trying to deploy a Windows 8.1 image. I've create a unattend answer file with Windows System Image Manager. The answer file validates. I've added this answer file to the WDS server properties client tab under the proper architecture (x64). I am still prompted to input locale and credentials even though my answer file has this information already in it. On the client, the setupact.log file says, "There is no unattend file available on the server." I am confused because I see the file and I am able to browse to it from another computer on the network. I've created another post on TechNet. <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <WindowsDeploymentServices> <Login> <Credentials> <Domain>DOMAIN</Domain> <Password>PASSWORD</Password> <Username>USERNAME@DOMAIN</Username> </Credentials> </Login> </WindowsDeploymentServices> </component> </settings> <cpi:offlineImage cpi:source="wim:c:/sources/install.wim#Windows 8.1 Enterprise" xmlns:cpi="urn:schemas-microsoft-com:cpi" /> </unattend> Any guidance would be greatly appreciated.

Possible. I feel like I've seen a message about a corrupted WMI in the log before. By chance did you ever try to repair WMI? From my understanding, you can rebuild WMI on the client machine.

Thanks. I don't really want to install Exchange in my lab environment but I guess it couldn't hurt. I'll look into 3rd-party addons as well. We are just trying to find a smoother way for users to request software and have it approved. Ideally, we'd like our HR department, or at least a representative from this department to approve requested software based on our MSDN subscription number. We find that the process of tracking who has what license to be rather cumbersome (in the MPN and MSDN sites). I found a great article about using System Center Orchestrator and creating an ASP.NET application to do pretty much exactly what I want. I am going to try this out. Thanks again for the information.

When a user request software from the Application Catalog that must be approved, does an e-mail get sent out to the approver and or Administrators?

Based on this information, it appears that it's having issues finding the distribution point. Have you installed a distribution point on the server where you copied the client files to?

I've tested on Windows 8.1 and it works for me. Have you tried reinstalling the client?

Have you setup the Application Catalog in the Client Settings? Administration > Client Settings > Default Client Settings In the Computer Agent section, make sure a Default Application Catalog website point has been set.

Ah, that's what I was afraid of! So now, I will try to manually remove the SCCM client from the device, remove the device from the SCCM console/database and try again. Do I need to kick off any Site Maintenance tasks?