18 January 2009

NS7: Inventory Installed Software Report

As I was playing a bit with NS7 (Or should I say Symantec Management Console) and Inventory I found a new report in the right click menu action of a resource called Installed Software on on the left side of the Resoucemanager.

First thing I did was deploying the Inventory Plug-in and I launched a task to get the inventory. When I then clicked the resource and opened the report it was empty (No result).

So i analyzed the report and it uses the Add/Remove Program information. But...other then Inventory Solution 6.X this information is now collected by the Software Management Framework Agent. This plug in is part of the core Agent.
Only...Software Discovery will run at 02H00...and then my VMWare is/was not running...So for those who are in a hurry on getting some information you need to change the Software Discovery Task schedule to run when you want.

After that this report is displaying some results.

17 January 2009

Hardware Independent Imaging with DeployAnywhere

On the juice site I found this article on using DeployAnywhere

Some other (and same) information comes from the KB articles

How to use DeployAnywhere in Deployment Solution to replace the HAL, NIC driver, and mass storage drivers


DeployAnywhere works by deleting the existing HAL.dll in a Windows* operating system and deploys a NIC driver and mass storage driver to rebuild the HAL.dll on the first reboot.

Requirements

        • Deployment Solution 6.9 SP1
        • Any image created with RapiDeploy, Ghost, or ImageX.
        • Windows PE Automation Enviroment

Steps to complete

  1. Create an image with RapiDeploy, Ghost, or ImageX.
  2. Create a Distribute Image task and check Use DeployAnywhere hardware independent imaging in the Configuration section of the task.
  3. Check Prepare Using Sysprep.
  4. Assign the Image Task with DeployAnywhere settings.

How do I test if the driver database has drivers for a computer?


  1. Boot to Windows PE* 2.1 network enviroment.
  2. Run these commands:
    cd F:\ghost
    ghDplyAw32.exe /target=c:\windows /ddb=F:\DriversDB /eval
  3. This will return a failure or success. (If a failure is returned, it will say what driver is needed.)
  4. Important:
    The previous task only works if the SmeUtil.sys driver is in the
    \Windows\System32\Drivers folder of WinPE. This driver is found in the Ghost folder in your Deployment Share. It can be added to the WinPE automation during the creation or editing process by right-clicking the Drivers folder and selecting Add File.
    As an alternative, the SmeUtil.sys driver can be copied by adding the following command to your run script task:
    Copy %ALTIRIS_SHARE%\Ghost\SmeUtil.sys %SystemRoot%\
    System32\Drivers

NIC and mass storage drivers need to be added to the DeployAnywhere driver database.


  1. Open the Deployment Console.
  2. Click Tools, and then DeployAnywhere Driver Managment.
  3. Click on network for NIC drivers and mass storage tab for mass storage drivers, and click Add New Driver.
  4. In the New Window Driver window browse to your drivers. In the friendly name box, type a name for the driver you are adding. Check the OS that this driver will be applicable for.

To enable Deploy Anywhere logging with Deployment Server do the following:


        • Open the applicable Distribute Disk Image job.
        • Select 'Use DeployAnywhere hardware independent imaging'.  The 'Advanced' button will become active. (not grey)
        • Click on the 'Advanced' button.  In the 'Additional Parameters' box add the '/capturesupportinfo=<path on DS to store the logs>' switch.  E.g. /target=c:\windows /ddb=\driversdb /capturesupportinfo=f:\temp.

    When Deploy Anywhere is ran it will output all logs to the directory specified. 

11 January 2009

What is the best way to change the IP address of the DS server?

You should check and change the IP address of the DS server in the following places:

  • Change your aclient settings over to point to the new IP address (or the server's hostname if possible)
  • Stop the Altiris eXpress Server, PXE Config Helper and PXE Manager services
  • Change the IP information within these files in the eXpress share:
    • .\default.cfg
    • .\pxe\pxe.ini
    • .\pxe\pxemanager.ini
    • .\pxe\rpc.ini
  • Start the Altiris eXpress Server, PXE Manager and PXE Config Helper services (Note the order of start up)
  • Change each PXE / Bootworks configuration to point to the new IP address (lmhosts file)

04 January 2009

Configuring Package Location on your Package Server

This article shows you how to:

  • Change the package location
  • Secure the package location

Changing the Package Location

It can be beneficial to select a different location on your Package Servers to save disk space. When the storage location for a package is changed to a custom location, the Package Server: 

  • Moves the files from the old location to the new location
  • Deletes the old location
  • Checks what is to be downloaded

When files are removed from a package, the Package Server deletes them when it refreshes the package. However, removed files are not deleted if the package has a custom location as it cannot determine if the files are part of the package. Example: several packages with the same destination or the custom location contains user files.

Also, as the Package Server is installed on the same drive as the Altiris Agent you can select a different drive when installing the Agent.

This option is on a per package basis. What that means is that each existing package and all new packages would be configured this way. There currently is not a way to globally change the default location of the packages stored on the package server. All packages will continue to have the default location of "%ProgramFiles%\Altiris\Altiris Agent\Package Delivery". The only way to change this location is by removing the Altiris Agent completely, implying the removal of all subagents, then reinstall the agent on the desired drive.

Changing the Package Location

  1. In the Altiris Console, click the Configuration tab.

  2. Example:
    To change the Altiris Agent package location, in the left pane select Altiris Agent > Altiris Agent Rollout > Altiris Agent Package. In the right pane, click the Package Servers tab, select Package Destination Location on Package Servers and enter a location in the field provided.
  3. In the location field, specify a directory path or use system environment variables found on the Package Server. The following are valid paths:
    c:\share\<packagefoldername>
    f:\<packagefoldername>
    \\%COMPUTERNAME%\share\<packagefoldername>
    \\%COMPUTERNAME%\eXpress\<packagefoldername>
    /var/packages/<packagefoldername>

Warning: Ensure you specify a subfolder that is unique to each package in the Package Destination Location on Package Servers field!

If you do not specify a sub-folder, or use the same folder for more than one package, this can create a dangerous situation that could remove the entire destination folder and its contents. It is absolutely imperative that you configure an appropriate sub-folder when performing this task; otherwise the contents of your entire share could be deleted when the package is deleted!

When a package is removed (either by it becoming invalid or by manually clearing the Package Destination Location on Package Servers field) then the entire folder that the package resides in will be deleted, including any other files originally located there that were not part of the package.

Remember, ensure you specify a folder for each package in the Package Destination Location on Package Servers field!

Securing the Package Location

This section shows you how to:

  • Secure the package location
  • Allow anonymous access to package locations
  • Disable location security

The Agent Connectivity Credentials (ACC), in the Global Altiris Agent Settings page, are used by the Package Server to add file-based security to download package files, if so configured.

Note: The Agent Connectivity Credentials used must be a known account on the Notification Server and every Package Server.

To secure files in packages on the Notification Server and Package Servers configure Windows NTFS file permissions. If the user account can’t be validated on a Package Server (for example, non-trusting domain or computer account from another computer), Altiris agents won’t download files from this Package Server.

Using a domain account as the ACC will work if the Altiris agents, Package Servers, and Notification Server exist in the same domain, or a trust exists between the multiple domains in your environment.

If your environment contains multiple domains and no trust exists between these domains, when you specify an ACC, enter a local user account name and not a domain account user name and password. The format for entering the local user account name as the ACC is one of the following:

  • .\localuser
  • localuser (where localuser is the name of the local computer account)

If you specify a local account as the ACC, we recommend you enable the Create the Agent Connectivity Credential on Package Servers option on the Settings tab of the Package Server page (provided the ACC is not a Domain Controller). This ensures a local account will be created and applied to the downloaded package files on all Package Servers, if it doesn’t already exist on all Package Server computers, on all trusted and non-trusted domains.

The Altiris Agents can use this local account to connect to Package Servers across nontrusted domains when downloading files.

If you specify a local account and the Create the Agent Connectivity Credential on Package Servers. (provided the ACC is not a Domain Controller) option is disabled, the local account needs to already exist on every Package Server. If not, the Package Server can’t apply security to downloaded packages and will not publish codebases as ready to the Notification Server.

Creating the Agent Connectivity Credential on Package Servers

  1. In the Altiris Console, select the Configuration tab.
  2. In the left pane, navigate to Configuration > Server Settings > Notification Server Infrastructure > Package Servers.
  3. In the right pane, click the Settings tab.
  4. Select Create the Agent Connectivity Credential on Package Servers (provided the ACC is not a domain account). Selecting this option allows you to enable the following:
    • Re-enable the created local account if it has been locked out.
    • Create the ACC even if the Package Server is also a Domain Controller.

Allow anonymous access to package locations

You can enable all packages downloaded to Package Servers to have anonymous access applied to the directories containing the package files. Anonymous access will also be enabled for the directory security inside IIS for the hosted Package Server packages.

If this feature is disabled the Agent Connectivity Credentials on the Global Altiris Agent Settings page will be used when applying security to the Package Server files. Any HTTP virtual directories mapped to packages on the Package Server will then have Integrated Windows authentication enabled.

All authenticated users are allowed to download through UNC when anonymous access is enabled. For example, if a Package Server in a non-trusted domain has anonymous access enabled on its files and the ACC account the Altiris Agent uses to connect anonymously to the UNC source cannot be authenticated, access with be denied and no download will occur. However, you can download through HTTP from a Package Server, in a non-trusted domain, using anonymous access because the ACC account doesn’t need to be authenticated.

New Registry key for disabling Package Server directory security

A new Package Server registry key, EnableDACLManagement, has been created to allow you to change how a Package Server manages the security on its packages.

By default, a Package Server manages its packages by setting specific permissions on package directories; this includes overriding any custom permissions you may have set on the directories. When this registry key is activated, Package Server will no longer override existing permissions on package directories.

Take care when using this key as incorrect permissions could potentially render the Package Server directories inaccessible to the Package Server and Altiris Agents.

To ensure a fully functional Package Server, full control for Local Administrator and System need to exist on all package directories in addition to any other custom permissions.

Normally, Altiris Agents and other Package Servers access the packages located on the Package Server computer using the Agent Connectivity Credential (ACC), configured on the Notification Server. To ensure they continue to download packages, configure the Everyone or ACC account with read and execute privileges on the package directories. This is required because when the key is activated, Package Server is instructed not to manage permissions, which includes not applying the ACC or Everyone account to the downloaded packages.

Creating the Registry Key

As the registry key does not exist on a default install of the updated Package Server, create the DWORD key, 'EnableDACLManagement' under the following location in the registry—HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Package Server. Before creating the key, stop the Altiris Agent Service and restart when finished.

The registry key can have one of the following settings:

  • 0—Ensures that Package Server will not change existing security on package directories.
  • 1—Will cause Package Server to function as normal by applying and resetting permissions on package directories.

03 January 2009

Altiris Deployment Solution 6.9 SP1 MP1 (Maintenance Pack 1)

What issues have been fixed in Altiris Deployment Solution 6.9 SP1 MP1 (Maintenance Pack 1)?


Resolution

The DS 6.9 SP1 MP1 (Maintenance Pack 1) addresses the component issues noted below:

Altiris Client Service (AClient.exe)

The current build of AClient is 6.9.366. It is a cumulative build that includes fixes from all previous builds.

Description Fixed in Build Article ID
AClient JPN, FRN, DEU, and CHS localization issue. 6.9.359 44291
Altiris eXpress Server (AXengine.exe)

The current build of AXengine is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description Fixed in Build Article ID
MMB S3 Bladeservers not listed in Deployment Solution console 6.9.361 44804
ASDK for DS

The current build of the ASDK for DS is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description Fixed in Build Article ID
DNS settings are not reflected on the console using a programmatically created Reconfigure job 6.9.361 44455
Authentication failing using ASDK methods like DeleteComputer() after installing DS 6.9 SP1 6.9.363 44253
''Task_Return_Codes_Table'' dataset is ignored in API calls 6.9.364  41438
CreateJob error in Administrator SDK 1.4, "Error Value cannot be null" when job have Condition set 6.9.364 40878
"Value cannot be null..." when DS security is disabled and code does not include DSCredentialsHeaderValue. 6.9.365
44650
Method failed. Exception: Permission Denied: Deployment Server Role-Based Security is enabled. 
6.9.365 44649

Boot Disk Creator (bootwiz.exe)

The current build of the boot disk creator is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description Fixed in Build Article ID
Boot Disk Creator unable to add drivers to WinPE using the Have Disk button 6.9.357 44108

DAgent

The current build of the DAgent Default Component is 6.9.366. It is a cumulative build that includes fixes from all previous builds.

Description Fixed in Build Article ID
Copy File task using UNC path fails with “The network path was not found.” 6.9.356 44031
DAgent does not retain WINS IP address after post config  6.9.361
44811
Duplicate SPN error when user tries to login to the machine with domain user  6.9.361
44807
DAgent in WinPE occasionally fails to connect to Deployment Server 6.9.366 44898
DAgent can hang if an exception is thrown during startup 6.9.366  44899

Data Manager

The current build of Data Manager is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description Fixed in Build Article ID
Exception may be thrown in Axengine if the Web Console is installed 6.9.361
44109
Deployment Server Console (eXpress.exe)

The current build of the Deployment Server Console is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description Fixed in Build Article ID
Cannot schedule jobs using Active Directory group authentication. 6.9.361
44235
Error "##wc_last_effective_rights" is displayed when multiple consoles are open 6.9.361
44220

PXE

The current build of PXE is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description Fixed in Build Article ID
PXE Server fails to send path to pxeboot.bdc when clients boot to WinPE causing ‘Windows failed to start’ error 6.9.362
44281
To apply the maintenance pack do the following:

1) Download the maintenance pack and save to a directory on the Deployment Server.
2) Execute the file and follow the prompts.  
Notes:

- All affected files are backed up.  An uninstall is added to Add/Remove programs in the Control Panel.

- Fixes are applied for installed components ONLY. If, for example, the ASDK is not installed, the ASDK fix will not be applied.  If the ASDK is installed later simply rerun the maintenance pack and the file(s) will be updated.
- The maintenance pack can be installed silently by using the /S switch.

-  In order for the maintenance pack to resolve the PXE and Webconsole issues documented above it is necessary to run the maintenance pack on all remote PXE/Webconsole servers. 

This can be done by following the steps below:

1) Install Aclient/Dagent on all remote PXE/Webconsole servers
2) Create a Distribute Software job. Use "DS_69_SP1_MP1.exe" with the /S switch.
3) Assign the job to the remote PXE/Webconsole servers
4) The maintenance pack will update the remote PXE/Webconsole servers
5) Remove Aclient/Dagent on all remote PXE/Webconsole) server