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
scotthansenpaysoneast@gmail.com | 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.

DECLARE
 @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 ;-)

viddect | 06 Dec 2007 | 0 comments

Here's a clever workaround if you're striving to boot Linux automation on an HP7700.

  1. Create a Linux automation PXE image.
  2. Browse to Program Files\Altiris\eXpress\Deployment Server\PXE\Images\MenuOptionXXX\X86PC where XXX corresponds to the image created in step 1
  3. Open pxelinux.cfg, and add "pci=conf1" (without the quotation marks) somewhere in the APPEND line.
  4. Save changes to pxelinux.cfg

This will only effect the preboot in question and not all Linux pre boots.

Jason Gallas | 05 Dec 2007 | 1 comment

I wanted a way to launch an Altiris job from a VBScript. After doing some searching online I realized that the axsched.exe command can do this. Here is a subroutine that I created that will launch an Altiris DS job on the system running the VBScript using axsched.exe.

In bold is the actual calling of the Sub that would go in the body of your script. Beware of any quotes in the Deployment Server job names as this will break the vbscript!

This script could be used either in an afterscript on a deployed image to install additional software or could also be called later as a departmental afterscript, installing all the software necessary for a particular department.

Call ScheduleDSJob("job name")

Sub ScheduleDSJob(strJobName)
  
  Dim WshShell, WshNetwork, strDPServer, strDSPath, strComputerName, strTime
  
  Set WshShell = CreateObject("WScript.Shell")
  Set WshNetwork = CreateObject("WScript.Network")

  strDPServer = WshShell.RegRead("...
helionit | 05 Dec 2007 | 3 comments

Helion IT (Altiris Gold partner) made a streaming demo of Altiris Deployment Solution with textboxes (dutch). In this online streaming demo you can see how Deployment Solution works in combination with an hardware independant image.

aphud | 30 Nov 2007 | 0 comments

I recently assumed that when we scheduled a Deployment Solution job to the "All Computers" group that when the schedule got ready to run it would check the current contents of the "All Computers" group and run the schedule to include any computers added after the scheduled job was first scheduled. I was so sure of my assumption I went about 3 weeks before I realized that... I was wrong!

In our environment, we run a number of scripts against our clients to make sure they are configured properly and to do quick updates. Deployment Server is a natural place to do this and be able to see the results in real time.

In reality, this only applies to the members of "All Computers" at the time the scheduled job was created. Therefore, any machines that had been imaged and put in production were not being updated.

I put in a feature request with Altiris Support for this, but they suggested a complicated work around of comparing the SQL tables at the time it was created...

Nelo | 27 Nov 2007 | 10 comments

As we prepare for a new deployment of Deployment Solution 6.9, IT personnel may encounter difficulties using WinPE 2.x in conjunction with VMWare network drivers. In addition, as more and more users try to virtualize their environments, Microsoft Vista users might find themselves without networking in VMWare Virtual Machines.

There is little known work-around for this issue: make the virtual machine load up the Intel e1000 network driver. Forcing this change will make virtual machines think they have an e1000 network driver and load up the network. This also prepares Virtual Machines to run automation jobs in a pre-boot environment using this driver instead of the VMWare drivers.

The following works for VMWare WorkStation 5.5 and 6.0 and VMWare Server 1.0+. By make the following alterations, WinPE 2.x will work seamlessly with network drivers.

  1. Make sure VMWare is not running. Stop any VMs running and close VMWare.
  2. Browse to the Virtual machine...
riva11 | 27 Nov 2007 | 0 comments

Nel caso di una nuova installazione di Deployment Solution 6.9, il personale tecnico IT può incontrare delle difficoltà nell'uso di WinPE 2.x in abbinamento con i driver di rete di VMWare. In aggiunta come ulteriore considerazione, sempre più utenti provano a virtualizzare gli ambienti di lavoro, e con Microsoft Vista possono incontrare delle difficoltà non avendo la possibilità di usare connessioni di rete con le Virtual Machine di VMWare.

Per risolvere questo problema è possibile applicare una piccola modifica: fare in modo di assicurare che la virtual machine carichi il driver network della scheda Intel e1000. Forzando questo driver si forza il caricamento del driver di rete in modo da avviare la connessione di rete. Questo inoltre consente di preparare le Virtual Machine a eseguire job automatici in ambiente pre-boot usando questo driver invece dei driver nativi di VMWare.

Le seguenti modifiche sono valide per VMWare WorkStation 5.5 e...