Peter van der Woude

The client is either installed or not. When the client is installed the problem can't be related to permissions on the server-side... Did you really go through the log files and are you absolutely sure there isn't something going wrong in the task sequence?

The issue is indeed most often related to the client installation. If that installation is already started you should find the log files in C:\Windows\ccmsetup\Logs.

You can also work only with remote distribution points, but the easiest method will be to use the boundaries and boundary groups.

That shouldn't be to difficult as they are both using the same classes. I think it could be something like this (haven't tested it): select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.SystemType = "x64-based PC" and SMS_R_System.NetbiosName like "Example" and (SMS_R_System.OperatingSystemNameandVersion like "%Workstation 6.1%" or SMS_R_System.OperatingSystemNameandVersion like "%Windows 7%") As you might also notice I've changed the operating system check. This is to assure that both options are valid, although I think that the second option doesn't even exist.

Return code 0 is a successful installation...

Correct, to use task sequence variables you have to put those percentage signs around them.

It differs per customer, as they all have different wishes. I've had a customer that wanted to manage those HP ThinClients via ConfigMgr, but I've also had a customer that didn't want to pay additional licenses for those HP ThinClients and accepted the security risks. It's all choices and even I don't always like the choice the customer makes. For the VDI the same, you can build the base image via ConfigMgr and deploy applications and updates, but again it's all about requirements. I also had a customer that wanted to use App-V standalone for the (virtual) application deployment as it responds more instant than ConfigMgr. Main point, make sure that you list the requirements correct and make your choices based on that. ConfigMgr can do it all, but even I have to admit that it's not always the best choice for every component...

I would start by testing the "script" via PSEXEC to run the "script" with SYSTEM credentials like ConfigMgr does.

Microsoft Security Essential is not a managed product, so I assume that's why it's not looking at WSUS. If you want to manage your antimalware agent you need to look at the Endpoint Protection agent.

It depends on various things, what type of VDI are you talking about? Also, the management of the thin clients depend on the type and the OS. I've had customers where we managed the thin client with ConfigMgr, as it was Windows 8, but I've also seen WISE zero clients that had their minimalistic firmware pushed by own software.

It doesn't have to be MDT, but using the MDT scripts could help with creating those variables.

Look at PowerShell. You can use it to read the CSV and create membership rules via the cmdlet Add-CMDeviceCollectionDirectMembershipRule.

Correct, by default compression is enabled. To migrate specific folders (or not) you can use the migration XML files, in this case even the default ones. For more information see: http://technet.microsoft.com/en-us/library/hh825256.aspx

If it's not a "standard" update then you can get that information on a client via Win32_QuicFixEngeneering. To get that information you can extend your hardware inventory. In case you don't want all that information on your server you can also use DCM to run the check on the client and only report the results.

It will always generate a log, you just didn;t specify a location. The standard location is C:\Windows\Temp

What error are you running in to?

It's also part of the guide you're following, it's located under the header "CLIENT CERTIFICATE".

In that case I indeed wouldn't worry about migration or backup-restore actions. With a software update scan by a client you've got the compliance state of a client back, that's not really something that needs to be migrated. Keep in mind that you need to reinstall the client to point it to the new site (there are other ways, but this is the easiest).

It looks like you didn't deploy the client certificate on your management point server.

What type of deployments are you talking about? Packages or Applications? Also, are the deployments deployed to users or devices and as required or available?

It's trying to do a healthcheck and it can't find a client certificate to use. Make sure you've got a certificate available with client authentication capabilities.

1603 is a generic MSI error. You need to find the adobe installation log file as it will provide more information about the error.

It looks like your trying to publish the ConfigMgr client via the SUP/WSUS. Are you using the software update point client deployment?

Migration also handles 2012 > 2012 migrations.

Personally I indeed think that it would be over-complicating matters, mainly because your basically remediating with a remediation. Like that it even sounds like a duplicate