Peter33

It just means that the driver package is not replicated to your distribution point.

Well, unfortunately you can't do that with SCCM. This is a client monitoring task and you would need SCOM for it. If you don't have a SCOM license you could simply write a lil vbscript which will be triggered by the client logon/logoff and let it write the results (client name/user name/datetime) to a sql database. The script can be applied to the client with a group policy (User Configuration\Administrative Templates\System\Logon/Logoff).

Just double click your task sequence and go to the advanced tab. Make the task sequnce available only for Vista x64. In the boot order make sure that the HD is the first boot device of the clients. Finally put a password on the PXE points. This way you don't have to worry that someone accidently triggers a reimaging of your whole environment. You can't see who cleared the PXE flags because this action is not altering the collection.

Actually there is no adequate replacement for this zenworks feature. We solved this by creating a Link Folder shortcut for every location pointing to a network drive folder which holds the necessary shortcuts. This way you can replace or modify the shortcuts on the fly without pushing them to every client over and over again.

First you need to add ADSI support to your PE. Then you can provide the credentials for the AD logon in the script itself, or just chose the "run command line" in the task sequence, where you can sepcify a user account. Put the script in the MDT script folder and run "use toolkit pakage" as the first step in your TS. In the command line just call the script from the MDT script folder.

Just add a schedule to make it mandatory and remove the checkmark for "allow user to run .... " in the interaction tab of the advertisement. If you are using a task sequence also uncheck the "show task sequence progress" option.

Have u added the command line options /install /silent to the exe files?

OK, just try the "Auto Apply Drivers" instead of applying the driver package. If the drivers are still missing find out which drivers are affected. Maybe you need to create a software package for them. Also check if you can manually install the drivers by pointing Windows to the the driver package path. Just by the way, did you download the latest drivers for this model?

If i understand you right u mean the DNS Suffix List? This should be configured with group policies (Administrative Tools/Network/DNS Client).

Have you defined an AD account for SCCM that has local admin rights on your clients?

This method sounds legit and good. But the question is if you don't want to use the opportunity of the migration to clean up your software portofolio and your license management.

Is there a reason to change the DNS settings by an application? This is a classic DHCP Server task and will be configured in your AD.

Disable the local caching for the advertisement to see if the setup will run as expected. If yes, your IIS is blocking some file types. Also activate the logging for the setup and inspect the log file.

Activate the "unsigned drivers" option checkbox for the package in your task sequence.

First, don't use the exe file to deploy winzip because this will not customize your installation. Second, looks like you are installing a 30 days trial since you don't bypass a serial number. So if you don't have a volume license for winzip rather use 7zip instead. It's free and has all features you need. If you want to deploy though winzip you should take a look at appdeploy how create a proper package for deployment. It's the best source for application deployment and has solutions for many products.

You can set the variable in a script by using env("OSDComputerName") = computername, and yes you can also set the name by setting a task sequnce variable. Best practice for naming computers is using the serial number of the client machine.

Sounds like you did not inject the NIC driver for this machine type.

Hi, looks like u were trying to call the copy without "cmd /c". copy is a cmd command and no executable.

Check the ccm.log on you Management Point and the ccmsetup.log on your clients. If you have more than 1 Management Point you have to disable the Client Push installation on all of them.

Well, you have already the deafult collections for Windows 7 and for Windows XP. So instead of joining the 2 queries in your new collection (XP+7) go to the membership rules of this collection and create 2 new queries. You don't have to edit the query statements of these queries. Just limit them to the Windows 7 and Windows XP collections.

I wanted to post this for a long time now, but always forgot it. I had to slightly modify the script because there is an design error in the objGroup.GetEx("member") function. THis causes the script to fail if the AD Group is empty. So here is the modfied part which will avoid this problem. ' objGroup.getinfo Set objComputer = CreateObject("WScript.Network") Dim strComputer strComputer = objComputer.ComputerName On Error Resume Next arrMemberOf = objGroup.GetEx("member") 'Loop through group members If (Err.Number = 0) Then On Error GoTo 0 For Each strMember In arrMemberOf If InStr(UCase(strMember), UCase(strComputer)) > 0 Then 'Match found, edit variable and exit oEnvironment.Item("INSTALLAPP") = True WScript.Echo "Is a Member: " & strMember & " - " & oEnvironment.Item("INSTALLAPP") WScript.Quit(0) End If Next Else oEnvironment.Item("INSTALLAPP") = False WScript.Quit(0) End If 'No match, just exit Just by the way. Great Script. Using it for a good while now.

You also can create a query and use the Select instead of the single value. Bind it to the SystemResource.Name property with "is in". This way you can add the clients with copy and paste, one by one.

Just a hint. You don't have to join the queries to get this result. Just create 2 queries in your collection holding the original query of one collection. This will help you to avoid unexpected results, especially if you have already advertisments applied to the colection.

Well, it matters. But not that much. The syntax is just slightly different. Look here. I am still thinking that the problem is caused by the %deployroot% variable. If the options txt is placed in the package folder just replace the path by ".\Scripts\CustomScripts\Options.txt".

Copy the font file to C:\Windows\Fonts and create a registry entry in HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Fonts (REG_SZ), named with the font name, and the set the value to the file name..