Video Screencast Help
Endpoint Management Community Blog
Showing posts tagged with Altiris Deployment Solution
Showing posts in English
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.


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...

callumj | 31 Jan 2008 | 0 comments

When deploying the Adobe Creative Suite 3 Master Collection most of the application overrides are all good to get the software configured and deployed. One of the problems with deploying Adobe Acrobat is that it needs to have Photoshop run beforehand. Sadly, some users just don't get it and end up running around in circles and calling the helpdesk.

The solution to this is to run a remote command executing the photoshop.exe as a local user and then rebooting the machine. This will prevent Acrobat from prompting users the next time they try to use it.

callumj | 23 Jan 2008 | 3 comments

Netdom is one of the best ways to automate adding a client to a Windows domain, forget having to mess around with sysprep or manually adding clients to a domain when you can run a simple batch script.

My dilemma for the need of NETDOM spawned out of Altiris issue which was none of the Altiris deployed images were not adding to the domain, even though they were being forced to by the Altiris client. This was driving me nuts that the majority of the deployed computers were just sticking to the workgroup.

The main solution is sysprep images, which is what should be done in the long run but redoing an image is messy and annoying if I want it all done in a day. After remembering that Altiris Deployment Solution allows the remote execution of scripts and batch commands, I crafted up a job that solved my problem and deployed them all in a day... | 17 Jan 2008 | 2 comments

When creating jobs that will be reused in an installation of Deployment Solution, export the jobs to a folder on a hard drive other then the hard drive where the Deployment Database is stored. In this way the jobs can be imported back into Deployment Solution if the jobs are accidentally deleted. This will also safeguard the jobs if the Deployment Server and/or Deployment Database have to be rebuilt from scratch.

The steps required to export the jobs are best done by gathering the jobs into a folder within the Jobs pane of the Deployment Console. Once the jobs are in one folder, right click this folder and selected Export... The Export Selected Job(s)/Folder(s) dialog comes up and you can browse to a place on you network drives where the file can be saved.

Give the file a name and Click on OK.

To assure that the export was good, import the folder back into your Deployment Console under a Test folder and then check the subfolders to make sure that all of the...

robertser | 21 Dec 2007 | 1 comment

Depending on the way you have your SQL database security set up you may end up with stored procedures and other objects having an owner other than dbo. The typical case of this happening is when running the upgrade with an account that is not an SA on the SQL Server.

If unresolved, this naming issue can give you grief. Here's a way to fix it.

This ownership issue will ultimately end up in causing a lot of errors such as the Deployment Console not opening or certain tasks failing. Basically anything that tries to call the stored procedure will fail because the name is wrong. For example: A stored procedure in the DS database called dbo.del_computer may have its name changed during an upgrade to username.del_computer.

To fix this situation run the following SQL script. Change the USERNAME to whatever the owner is for the objects that need to be changed.

 @OldOwner sysname,
 @NewOwner sysname

 SET @OldOwner = 'USERNAME'
 SET @NewOwner = 'dbo'...
viddect | 12 Dec 2007 | 0 comments

I ran into some issues while working on an imaging project that involved Solaris and adlagent. Here are the steps I took to work things out. Hopefully this will help the next IT guy in line.

The Problem

  1. Adlagent sends shutdown -r now down when rebooting a Solaris box to begin imaging.
  2. Adlagent doesn't install with correct parameters
  3. Errors when running /opt/altiris/../../bin/configure

Our Workaround

  1. Adlagent sends shutdown -r now down when rebooting a Solaris box to begin imaging.
    Resolution: in an imaging job you will have to put a run script task and put that as the first task. In the run task put "reboot" (without quotes). You might have to put "reboot -net" (without quotes) to force it to do a network boot.
  2. Adlagent doesn't install with correct parameters and
  3. errors when running /opt/altiris/../../bin/configure
    Resolution: Adlagent for Solaris will install but it...
kmieciooo | 06 Dec 2007 | 2 comments

Sometimes there is a need to slow down a software deployment. I had it once -- when deploying encryption software. In my case the problem was main encryption server -- which was not able to process more than 50 events from clients.

Here's how to sloooooow your deployment down a bit.

I was wondering how to deploy it slower to my more than 1000 machines. SQL helped me with simple solution -- which is -- using a SELECT TOP query in the target collection.

Simply create your target collection using the SELECT TOP ... query and it will be updated in next collection update cycle.

Enjoy your slow uptake ;-)