Obviously the preferred client installation method is either via an automatic client push or manually pushing out the client using the SCCM Administration Console:
However, this method sometimes doesn’t work either because of permissions issues or WMI corruption. Of course, you want to fix the underlying problem that is causing a manual client push not to work.
For those of you interested in an alternative way to install the client, you can use the excellent PSEXEC.EXE command-line tool from Mark Russinovich Sysinternals Suite:
PSEXEC.EXE command window with server names blurred.
psexec.exe \\RemoteComputer -s -d \\SCCMServer\SMS_SiteCode\Client\ccmsetup.exe /logon SMSSITECODE=ABC /MP:MPServer.domain.local CCMHOSTNAME=cm.domain.com
In the above example, PSEXEC.EXE initiates a remote connection to “\\RemoteComputer” using the System Account (/S) and then passes the command and terminates immediately (/D).
For a list of PSEXEC.EXE switches go to http://technet.microsoft.com/en-us/sysinternals/bb897553.
For a list of CCMSETUP.EXE switches go to http://technet.microsoft.com/en-us/library/gg699356.aspx.
I had a very strange issue today as I pulled a loaner laptop to test an application I was working on – turns out the machine would not PXE boot because its MAC address was already assigned to another machine in SCCM’s database. However, the UUID was different. In order to determine the issue, I built out the following two queries:
Find computer by MAC address:
select distinct * from SMS_R_System where SMS_R_System.MACAddresses = "aa:bb:cc:11:22:33"
Find computer by UUID:
select * from SMS_R_System where SMS_R_System.SMBIOSGUID = "AAAAAAAA-BBBB-CCCC-1234-567890ABCDEF"
The first query returned a machine in the database with a different name than the one I was working on but had the same MAC address (actually two MACs) and with a different UUID. The second query did not return anything when I inputted the UUID it displays when pausing at the PXE boot screen, but, after examining the contents of SMSPXE.LOG, I was able to see the last UUID that attempted to connect which was slightly different (some numbers seemed transposed) and when I used this it returned the same exact computer as in the first query (phew!).
I then started to investigate if the machine displayed in SCCM existed in active directory and sure enough, it was part of the domain. Furthermore, I was able to ping this machine on the network! Now I have certainly read before that it is possible to have a duplicate MAC address because of vendor error, but I didn’t think I am that unlucky. After asking the helpdesk about the computer being returned in SCCM, it turns out the user currently assigned to it was given a loaner laptop but its hard drive was replaced by the original hard drive which has the SCCM client installed on it. When doing inventory, it apparently picked up this new MAC address and updated its record in the database with the new value. When the user’s original hardware came back from repair, the hard drive was swapped back to the original laptop and because the previous MAC address was already in the database, the client didn’t update and did not drop the loaner’s MAC address.
Case solved! I removed the SCCM client from the original machine, deleted the computer in SCCM and reinstalled the client on the machine. Upon reinstalling, it recreated the computer record in SCCM with the correct MAC address and I was finally able to reimage the loaner machine and test my application.
NOTE: I wasn’t feeling adventurous, but in my research I came across the following Technet post. It details a SQL query you can use to manually remove the MAC address from the database. However, this is not supported by Microsoft and it could corrupt your database, so I left this as a last resort measure. 🙂
I was testing out an OSD task sequence when I noticed I had made a mistake and I needed to restart the task sequence. By the time I was able to force a restart, it was in the process of partitioning the hard drive. Anyway, upon rebooting and restarting the task sequence, I was receiving error message:
“The task sequence failed to start with error 0x80070570”
This was happening right after I was picking the task sequence and assigned a computer name to a task sequence variable. So I started doing some investigation using the F8 console window and noticed the hard drive had no partitions on it. In order to fix this issue, I ran diskpart.exe as follows:
select disk 0
create partition primary
select partition 1
format fs=ntfs quick
Then I rebooted the system with the following command “wpeutil.exe reboot”. After the system was booted right back into WinPE, the task sequence finished without errors.
From time to time, I have a need to extract a .MSI file in order to customize a deployment or directly import any .INF files into the driver cache in SCCM. Instead of searching for any uncompressed files within the Windows temp directories, I have found it is much easier if you leverage MSIEXEC.EXE’s administrative install option:
msiexec.exe /a [Path to MSI] /qb TARGETDIR=[Extract Path]
/a – The switch responsible for performing an administrative install AKA “Extraction”.
/qb – Displays a quiet basic UI.
TARGETDIR – Specifies a target directory to “install” the extracted files.
Here is a link to Microsoft’s MSDN site which details further switches you can use with msiexec.exe.
Also, while we are on the subject of MSI files, I recommend you work with ORCA for customizing your own transforms. This tool is only available with the Windows SDK Components but here is a link to download the orca.msi file by itself which is the only file you’ll need.
Today I was building out the final task sequence for the Lenovo ThinkPad X1 Carbon laptop I am configuring and while choosing the applications to install in the task sequence, I noticed all but one application was not listed in the list box to choose from. I went to re-check the application settings and found that under the Deployment Type, in the “User Experience” tab, the “Logon Requirement” was set to “Only when a user is logged on”. I then changed it to “Whether or not a user is logged on” and I was finally able to see the application in the task sequence.
It is also worth noting to make sure the installation behavior is set to “Install for system” and under the application’s main properties, in the “General Information” tab, you have checked the box for “Allow this application to be installed from the Install Application task sequence action without being deployed.”
While testing out an OSD task sequence, I was receiving error message “Task Sequence: [insert task name] has failed with the error code (0x80070490).” This particular error was hard to pinpoint a solution for because the smsts.log did not register any messages relating to this error.
However, the particular step this error was being triggered on was when attempting to apply an image. Right off the bat I knew something was wrong as my task sequence would first partition the disk and then apply the image. In other words, it was skipping the disk partition step.
After further inspection of the task sequence using the console, I noticed on the “Partition Disk 0” options, there was a condition specified to only run this step if the following Task Sequence Variable was met: “_SMSTSBootUEFI not equals “true”.
The particular laptop (Lenovo ThinkPad X1 Carbon) I was running this on has a UEFI BIOS enabled. While I didn’t disable this condition because I didn’t know why it was put there in the first place, the solution was to disable UEFI and enable the “Legacy” BIOS in the laptop. Once I rebooted and tried again, the task sequence applied without any errors.