Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog
Showing posts tagged with Deployment Solution
Showing posts in English
riva11 | 06 Mar 2008 | 0 comments

Nel caso sia stato creato un ambiente di pre-boot Linux (PXE, Automation BootDisk, Network BootDisk, ecc), ma per qualche problema non viene montato un disco che punta ad una condizione sul server DS. Come è possibile collegare manualmente da prompt"/#" una condivisione in modo da fare un test?

Eseguire il comando seguente:

"mount -t cifs -o username=[nome utente],workgroup=[workgroup/dominio],password=[password] //[dsname/IP/FQDN]/express /mnt/ds"

Se il comando ha avuto successo, viene visualizzato un prompt "/#", altrimenti si ottiene un avviso su schermo o un messaggio di errore.

Per controllare che sia stato montato correttamente, digitare "mount" che visualizzerà la lista di tutte le cartelle, device, ecc.

"cd mnt/ds" fornisce inoltre l'accesso alla cartella condivisa del server DS.

Digitando successivamente il comando "ls" sarà fornita la lista delle directory della condivisione sul...

SK | 05 Mar 2008 | 5 comments

A Linux pre-boot environment has been created (PXE, Automation BootDisk, Network BootDisk, etc), however, when it runs it fails to mount to the DS. How can the mount process be tested from the "/#" prompt?

Run the following command:

"mount -t cifs -o username=[username],workgroup=[workgroup/domain],password=[password] //[dsname/IP/FQDN]/express /mnt/ds"

If this action is successful, the "/#" prompt will return, otherwise an error or usage screen will be returned.

To check the mount, type "mount" which will display all mounted devices, directories, etc.

"cd mnt/ds" will provide access to the DS mount point.

Typing "ls" will provide a directory listing of the DS mount point.

scotthansenpaysoneast@gmail.com | 05 Mar 2008 | 2 comments

You just installed a Hot Fix that included a new AClient and you notice that as Auto Update is enabled, it only updates 15 clients at a time. You may find yourself asking, "How can I change the AClient Auto Update value from 15 clients at a time to a different value?"

When a newer version of AClient is installed into the Deployment Share, the managed computers automatically update their copy of AClient to match this newer version. Starting with Deployment Solution 6.5 Hotfix 2, the AClient Auto Update feature only updates 15 computers at a time, to reduce the network traffic used when a new version of AClient is installed.

To view or change the auto update value:
On the computer that Deployment Server is installed on, run Regedit.

Locate and select the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris eXpress\Options

Locate and double-click the UpdateAgentsConcurrentlyMax DWORD entry...

scotthansenpaysoneast@gmail.com | 03 Mar 2008 | 1 comment

You can reduce the size of your PC Transplant Solution folder by removing unnecessary directories or files, depending on your needs. You might find that you don't need to include many of the utilities that shipped with PC Transplant Solution. You might be surprised how little it takes to have the application work for you on your present or another server.

Try removing some of the following items and see if the program still works the way you need it to:

  • The AClient folder is 5.84 MB, and contains the 6.0.47 version and will not be needed if aclient will already be installed or will be managed currently by the Notification Server or Deployment Server.
  • Various language folders range from 7.5 MB to 8.29 MB. If you only need the English Language, only keep it and then your folder will be 40.3 MB smaller.
  • The License...
CondorMan | 29 Feb 2008 | 5 comments

If you plan on installing Vista Service Pack 1 when it is released (highly recommended), you might want to run the cleanup command afterward.

To do this, open the run dialog (Win-R) and type "vsp1cln.exe" (without quotes) and press enter.

This will remove the ability to uninstall the service pack (so make sure to test everything before running the cleanup), and it will cleanup 1GB worth of data off of your hard drive.

gbromage | 08 Feb 2008 | 5 comments

Recently, VMware released their Update Manager to handle patch management of ESX servers.

For those of you who haven't implemented it, here's a setup of reasonably robust scripts to do the patching via the Deployment console.

Use the ESX-100xxxx patch number as the job name.

1. Check to see if the patch is installed

#Check to see if this patch is already installed
#!/bin/sh
esxupdate query | grep %JOBNAME%

Set this job to STOP on a "Success" (exit code zero), and Continue (sucessfully) on exit code 1.

grep will return exit code 0 if the text is found (ie patch is installed), 1 if it is not.

2. Check that the host is in maintenance mode

#Check maintenance mode status
#!/bin/sh
#There needs to be a 2 minute delay, just in case this is running straight after another patch which caused a reboot
sleep 120
test `vimsh -n -e hostsvc/runtimeinfo | grep 'inMaintenanceMode' |awk '{print $3}' | sed 's/,//'` = true

...

ianatkin | 07 Feb 2008 | 0 comments

Many organizations can configure local environment variables on their systems that can detail useful information such as asset details, location or even printer configuration.

When imaging computers to fix issues, this information has to be uploaded to the server, so it can be restored as a post-imaging task.

The most obvious way is to run a script on the client which,

  1. Maps a drive to the Deployment Server
  2. Exports the selected environment variables as a batch file env-%ID%.bat in \Express\temp

Using this approach requires,

  1. Your Clients and DS to be in the same Domain, or a common credential to be shared across your PC estate
  2. Windows Networking to be reliable... ;-)

The Workaround

A workaround which we have found to be quite robust is to run a job before imaging a client computer which exports the required environment variables to fake Add/Remove program entries. These can then be picked...

BRING | 07 Feb 2008 | 0 comments

When using the high-powered personality capture capabilities of PC Transplant in a large migration, it sometimes make sense to use PCT from the command line. In one case, it was the only way that the tool was able to function to help in a migration project.

In this specific case, a custom capture template file was defined, and the command line parameters were properly set. Each time, however, the resulting capture file did NOT contain those targeted files and folders.

Why?

As PCT executed from the network share, all of the PCT files were supposed to be read over the network, either via UNC share, or mapped drive. It was also observed that the process took a substantial amount of time, almost excessive.

As a troubleshooting test, all of the contents of the PCT folder were copied to a temporary folder on the workstation,...

dfnkt_ | 04 Feb 2008 | 1 comment

Our company recently purchased several HP/Compaq 8510w notebooks.

When trying to capture an image from one (we set up to our standards) we received an error when PXE booting into WinPE. The machines boot into WinPE and then present a "Disk not Found" error. These laptops are using SATA hard drives so after some brief searching in the BIOS I Disabled a setting "SATA Native Mode" and retried the image capture.

The image capture took a little while but it completed successfully. Upon trying to deploy the image to the other machines, we ran into the same error. Again going into the BIOS and disabling SATA Native Support fixed the issue.

Maybe someone can shed some light on why this happens? I would think that you want SATA natively supported, but I guess not in this case.

gbromage | 04 Feb 2008 | 0 comments

Just a quick heads-up in case this affects anyone else besides me.

I have a scripted deployment for Windows 2000 servers. It operates doing a PXE boot in DOS mode, copies the install files from the depot and runs the install.

All worked well, until I moved the depot to a 64-bit Windows machine. It turns out, the DOS mode network client doesn't seem to play nicely with 64 bit Windows.

In this document, Microsoft says:

Q. Are there any features in the 32-bit versions of Windows that are not in Windows Server 2003 x64 editions?

A. A small number of features are not included in x64 Windows, including DOS, POSIX, 16-bit support, and a few legacy networking protocols no longer in active use.

So, something to keep in mind if you are running a hybrid environment. If anyone knows a workaround, aside from the obvious one of NOT...