Peter33

Same procedure as for VSTOR. Just extract the exe file and use the msi with "msiexec /i o2010pia.msi /norestart /q". Has also the benfit that you can use the application model and buld some nice dependencies with it.

Extract the exe file with 7zip and run "msiexec /i msiname /norestart /q".

Go to the properties of ths TS an make available to an OS you don't run in your environment, Like Vista x64.

I would say you just need to scratch the "\\pfsccm2007\Base Software Installs\" from your command line.

CMD sessions are always executed in the home path of the user running it, also during OSD. You only need to use the command line step if you want to apply the setting during the PE phase. If the machine is already rebooted to the installed OS you can use a regular "install software" step.

OK, forget about the BDD2007 since it was working already before. Can you open the TS on one of your servers, central or primary? Since you have different MDT versions installed, i guess you have just upgraded to 2010 and the TS stopped working then? If so, you should be able to open the TS on a computer with MDT2008 integration.

That seems to be some pretty old task sequence. I think you need to get a copy of BDD2007 and install it on some computer. Then edit the task sequence and get rid of all the old BDD steps in your TS.

The %~dp0 is not needed as long you don't use a batch file or a command line task sequence step. These two will start in the home path of the user. So batch files should always contain a "pushd %~dp0" as first line and "popd" as last line.

Hmmmm, rather try "netsh wlan add profile". There is no "import" command.

You're welcome. This depends on the schedule of your maintanance tasks and on the update cycle of your collections. Usually it's no problem though, because the old record is set to obseolete and will be delete according to your maintanance task (if its is configured?). Check the default values and lower them if needed. Update cycles for collections can be set to 1 hour without problems (default is 1 day). Don't know the default value for the cleanup task now. But the default is usually OK. You should check for invalid duplicate entries now and then though. They may be imported through the AD discovery. Happens pretty often for laptops in our environment when they have not been deployed with SCCM OSD. After a half year of travelling around the world they come back and get reimaged, but the old record stays forever until it gets deleted manually.

Running a command line with the following command should do the trick. You need to do this after every reboot in the Task Sequnce. Also make sure the interface name "Local Area Network" is correct on your machines. It differs depending on the OS language. netsh interface ip set dns "Local Area Network" static 192.168.0.1 This command will set it back to DHCP netsh interface ip set dns "Local Area Network" dhcp

You should always create your Apps, Packages, tasksequences on your Primary Site Server. This is your central Management Point. When you deploy your TS all needed packages will be deployed to the needed Distribution Points. So when you don't want your Primary Server to act as Distribution Point create a Disttribution Point Group which contains only your Secondary Server(s) and deploy your Software to this group. However, the boundary configuration is the key point to solve your problem. Assign the subnet to your secondary server.

Duplicate entries are normal, because SCCM will create a new object during OSD (different hardware ID). The obsolete object will be deleted automatically, if the client has been registered correctly before in SCCM. If not you have to delete the outdated entry manually.

Try to connect manually to the admin share of the client with the same and with a different a account. Verify the password for the push installation account. Make sure the client firewall is configured correctly. Also check your DNS/DHCP configuration, does reverse lookup work?

Did you perform a domain join with the machine during the OSD? You should also set the machine name in your TS to something reasonable.

No reason to be scared. It's really not that much work. mount -> add package -> unmount/commit Just install MDT on some computer. It comes with all the needed packages (cabs) and the newest PE. Most work will be to add the drivers to the new PE image.

First you need to add HTA support to your PE boot image. Check this out. If you are using MDT you can just copy the HTA to the script folder of the HTA and update your distribution ponts. If not, build a package. Then add a command line step to your TS which points to your package and simply put in the HTA's name as command line to launch it. With MDT the command line would look like %ScriptRoot%\my.hta

Try this instead and keep in mind that computernames are limited to 15 charcters in a domain. Sou you will probaly have to optimize your naming conventions. <html> <title>Name Selector</title> <hta:application id="NameSelector" applicationname="NameSelector" singleinstance="yes" windowstate="normal" caption="yes" showintaskbar="yes" sysmenu="yes" scroll="no" /> <script language="vbscript"> ' Global Variables. Dim strCampus Dim strSerialNum Dim strAppend Dim strComputerName Dim strLclUser Dim strLclPW Dim strComputer Dim objWMIService Dim objComputer ' Set Variables SET env = CreateObject("Microsoft.SMS.TSEnvironment") ' Obtain Serial Number strComputer = "." Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colSMBIOS = objWMIService.ExecQuery("Select * from Win32_BIOS") For Each objSMBIOS in colSMBIOS strSerialNum = objSMBIOS.SerialNumber Next strCampus = CampusSelector.Value strAppend = AppendSelector.Value ' Set Computer Name strComputerName = strCampus & "-" & strSerialNum & "-" & strAppend 'Set OSD Computer Name Variable env("OSDComputerName") = strComputerName function showCName() strComputerName = selOne.Value & "-" & strSerialNum & "-" & selTwo.Value msgbox strComputerName End Function </script> <body> <SELECT ID="selOne" size="1" name="CampusSelector"> <option selected>Select Campus From List</option> <option value='CAMP1'>CAMP1</option> <option value='CAMP2'>CAMP2</option> </SELECT> <SELECT ID="selTwo" size="1" name="AppendSelector"> <option selected>Select Teacher Or Student</option> <option value='T'>T</option> <option value='S'>S</option> </SELECT> <INPUT TYPE="button" NAME="ComputerName" VALUE="Display Name" onclick="showCName"/> </body> </html>

The HTA should be the second step in your TS right after the boot to PE step, and together with MDT the 4th step. There is an own section for HTA frontends in this forum where you can find a lot of stuff and examples. -Restart to Windows PE -Use Toolkit package -Gather -Call HTA

Well, the link you which you posted there shoud do the trick. I was'nt aware of the $Computername\accountname cheat. It's way easier than scripting it. If i had to script it i would create a csv file with all computernames. Then let the script ping the computers and if they are online check if the sccm client is already installed with wmi. If no client is installed launch a powershell remote session and call the setup from the server share. This would require a guest access to the share though. Conclusion, go with the link you found there. Less work and more reliable.

Depends on if you campuses have their own domain controller or at least subnets, and your T/S machines have at least one hardware part that makes em unique. If yes, you can easily script that or better let the customsettings.ini of MDT do the work for you. So in this case you could make it zero touch. If not, you can still create an HTA frontend with radio buttons for T/S and a pull down menu for the campus to make it a lite touch deployment. You should avoid to use different task sequences. The MDT gives you all the tools needed to create a dynamic single task sequence.

You can't push install the client on Workgroup clients, because SCCM is using an domain account for the installation. This account is unknown on Workgroup computers. You could script the installation and use the local admin account in the script or as you already said, you can install it manually. You may (will) run into the same problem when you try to deploy software to you clients later on.

All right. After all this i was completely rethinking the whole process again, because i noticed that i still had too much overhead. So i started to simplify my adobe installations. Here is what i did. 1. Creating the Base Application for the MSI in the Software Library - the source directory contains the MSI the MST and the Setup.ini -create new application - manually specify the application information - add a deployment type - Windows Installer Native - edit the program tab in the deployment type msiexec /i AdbeRdr1010_de_DE.msi TRANSFORMS=AdbeRdr1010_de_DE.mst /q - edit the requirements tab and add windows 7 as requirement 2. Creating the Patch Application - the source directory contains the MSP and the VBS file - create new application - manually specify the application information - add deployment type - Script Installer Native - installation program : cscript.exe patchadobe.vbs - specify how deployment is detected -> Product code of the Base MSI but version of the Patch File - Installation requirements : Windows 7 - Installation Dependencies: add the Base Application for Adobe Reader Here is the script wrapper for the patching -------------------------------------------------------------- Set sho = Wscript.CreateObject("Wscript.Shell") strCommand = "msiexec.exe /p AdbeRdrUpd1013.msp /q" intRet = sho.run(strCommand,0,True) wscript.quit(intRet) ---------------------------------------------------------------- Finally deploy both applications to your "all windows 7 systems" collection For the next patch, let's say its 10.1.4 just replace the MSP file in the source directory of the patch application and the name of the file in the script. Then edit the deployment type in the patch application and change the version number in the deployment type detection. Update the distribution points and you are done.

Hi Howard, Settings Management is the former "Desired Configuration Management". It has nothing to do with SCUP, but it's a pretty nice feature and much improved compared to 2007. Anyways, why the admin install for version 10? You have to create a new AIP for every single patch again and the file transfer of the caching will be slowed down, because all files are being extracted and not held in the msi anymore. For the Reader this might be still ok, but for the Pro version that will be thousands of files. Also the supersedence should not be used to deploy minor version patches. As you said this will uninstall the old version and then install the new version. Not really the way you want deploy security patches. For Adobe X Pro the whole process would take like 30-40 minutes. My Adobe X applications for the base installations are script wrappers installing the msi together with a transforms file and right after that the latest available patch. For the patching of already deployed installations i am using regular packages.

Actually i am using the Settings Management to create role based non compliant collections to deploy the latest patches for the current installations of Adobe X Reader, Standard and Professional. The Settings Management has the benefit that i have always a quick overwiew of the compliance of my installations. AIPs are obsolete for Adobe X because the patches are now incremental. It makes no sense anymore because you have to start over from the beginning for every patch now. For Acrobat 9 it's still the way to go though.