1.  Summary

1.1 This document is the next in the series of my experience with the Symantec Management Platform project.  Specifically, the Mobile Device Management solution from Symantec.  

1.2  This document details the steps I took to configure the MDM solution in my environment. These steps worked flawlessly (after much trial and error) for me, but should be reviewed with your architect first to ensure they will work for your environment. Most steps will need to be modified based on your requirements for your environment, so please keep that in mind when reading through this article.

1.3  The second part to this series will detail how I configured profile encryption and security.  The link will be posted here once it has been published.

2.  Determine and document your Architecture

2.1  Even though we have multiple internal and external domains, we setup a few forward/reverse DNS resolvers (explained later) to allow us to go with what Symantec refers to in their documentation as a  ‘single domain’ architecture.  (We address this later with forward and reverse DNS look ups that resolve the SMM SS and the SCEP server to be used from either inside our network or outside).

2.2  Once you have your architecture model decided, go ahead and save yourself a HUGE headache and fill out this chart with the appropriate information.  (The data is just sample data)

2.3  Each of the above servers will need to be configured with the below required components

3.  Pre-Configure the  SMM Site Server

3.1 Login to the Symantec Mobile Management Site Server (SMM SS).

3.2 In ServerManager, click Features.

3.3  In the right-hand pane under Features Summary, click AddFeatures.

3.4  In the resulting window, expand MessageQueuing.

3.5 Expand Message Queuing Services.

3.6 Checkmark DirectoryServicesIntegration (for computers joined to a Domain).

3.7 Click the pop up that prompts you to add additional required features.

3.8 Checkmark HTTPSupport.

3.9 Click to add additional required features.

3.10  Click Next, and then click Install.

3.11 Install ASP.NET

3.12 Install IIS.

3.13  Ensure these are checked.

3.14 In IIS6 compatibility mode checkmark these:

3.15 Install the Altiris Agent on the SMM SS.

3.16  Verify agent functionality.

NOTE: I had a forward and reverse DNS resolution created to allow two-way name resolution both for inside our network (intranet) and from outside our network for the SMM SS and the SCEP/NDES server.  This is REQUIRED if you are to have your mobile agents installed and communicate both inside your network and from outside your network.

<SMM SS internal DNS>   <->   <SMM SS external DNS>

Ex. altirissite103.dir.jccc   <--> Altirissite103.jccc.edu

<SCEP/NDES Server internal DNS   <-->  <SCEP/NDES server external DNS>

Ex. ndes1.dir.jccc <--> -ndes1.jccc.edu

4. Install SMM Solution on SMP

4.1  Login to the SMP.

4.2 Navigate to Start | All Programs | Symantec | Symantec Installation Manager | Symantec Installation Manager.

4.3 After SIM launches, click Install new products.

• Select the latest Symantec Mobile Management suite and install.
• Accept the license agreement and click Next.
• Complete the install.

5. Configure Core SMM Site Server Role

5.1 Login to the SMP.

5.2 Click on Home | Mobile Management.

5.3  Expand Overviews and Reports in the left column.

5.4 Click on and work through the checklist and readiness checks in the right pane.

5.5 Mobile Management Server Status: select your SMM SS.

5.6 Wait about 30 minutes to re-check the status. You may tickle the SMM SS to expedite this process. Note, this only takes a few minutes in 7.5 according to Dave Giles of Symantec).

5.7 Reboot the SMM SS. (optional, but I like to do this)

6. Create SMM SS SSL Cert

6.1  Login to the SMM SS.

6.2  In IIS Manager, click on the server name in the left pane.

6.3 Double-click Server Certificate in the middle pane.

6.4 On the most right pane, click Create Domain Certificate.

6.5 Click Create Domain Certificate…

6.6 Fill it in as follows:

Common name: <external FQDN of your SMM SS>

Organization: <your company>

Organizational unit: <your group>

City/locality: <your city>

State/Province: <your state>

Country/region:  <your country>

Ex.          Common name: altirissite103.dir.jccc.edu

Organization: Johnson County Community College

Organizational unit:  Info Services

City/locality:  Overland Park

State/Province:  Kansas

Country/region:  US

6.7  Specify your local Certification Authority or use a public one (varies)

6.8  Give it a friendly name:  Ex. SMM SS 103.

6.9 Complete the request.

Note: Due to how our internal CA is set-up (I was granted permissions on the CA server to allow generation and issuing of web certs), my request was instantly completed and the request was immediately completed as I was able to find the newly issued cert in the MMC.

1. On the SMM SS, open MMC.
2. Add the Certificate Snap-In for Local Computer Account.
3. Expand Certificates | Personal | Certificates folder.
4. Right-click on the cert request you just completed and choose All Tasks | Export .
5. Choose Yes, export the private key.
6. Click Next  (accepting the PFX option).
7. Choose a location to export it to.
8. Copy that .pfx file to the SMP.
9. Login to the SMP.
10. In IIS, Server name, right click and choose All Tasks | Import and browse to the .pfx you copied over earlier.
11. Ensure it shows up in IIS Manager | Server Certificates (you may need to cycle IIS).

7.  ​Configure IIS on the SMM SS with new SSL Certificate

7.1  Login to the SMM SS.

7.2  In IIS Manager, expand Computer | Sites |Default Web Site in the left pane.

7.3  Click Bindings in the right column.

7.4 Click https then Edit (or click new if there is no HTTPS listed).

• Set IP address as All Unassigned.
• Set  Port to 443
• Select the new SMM SS cert  in the SSL certificate dropdown

7.5 Restart IIS.

8.  Obtain Root CA Certificate

8.1  Login to the SMP.

8.2 Open MMC.

8.3 Add the Certificate Snap-In for Local Computer Account.

8.4 Expand Certificates | Trusted Root Certification Authorities | Certificates folder.

8.5  On the non-expired Root CA certificate, right-click and select All Tasks | Export.

8.6  Click Next.

8.7 Accept the default DER encoded and click Next.

8.8 Browse to somewhere and save it. (Remember where this is!)

9.  Configure APNS Cert on SMM Site Server

9.1  Login to the SMM SS.

9.2  Click on the computer name in IIS Manager.

9.3  Click ServerCertificates.

9.4 Click CreateCertificateRequest… in the right pane.

Enter your information:

Common name: <external FQDN of your SMM SS>

Organization: <your company>

Organizational unit: <your group>

City/locality: <your city>

State/Province: <your state>

Country/region:  <your country>

Ex.          Common name: altirissite103.dir.jccc.edu

Organization: Johnson County Community College

Organizational unit:  Info Services

City/locality:  Overland Park

State/Province:  Kansas

Country/region:  US

9.5 Click Next.

9.6 Change bit length to 2048.

9.7 Click Next.

9.8  Specify location and file name to save as.

9.9 Click Finish.

9.10 In the Console, navigate to Home | Mobile Management.

9.11 Click on Settings in the left column, and then click on iOS Enrollment.

9.12 On that page, click the Request Signed CSR File hyperlink.

9.13  Once you receive the signed CSR visit https://identity.apple.com/pushcert using Firefox, Chrome, or Safari browse (not IE) and sign in with a valid Apple ID (you may need to create one for the purposes of managing your company’s mobile device certificates, or use your account if you wish to take the risk J )

9.14 Click CreateaCertificate and agree to the Terms of Use.

9.15 Select ChooseFile and navigate to the signed CSR that you received back from Symantec, and then click Upload.

9.16 Download that cert (.PEM file) to the SMM SS.

9.17 Complete the CSR request in the SMM SS and give it a friendly name (Global SMM SS)

Note: You will have to change the file type to *.* in order to see the .PEM file.

9.18 You should see the new cert in your MMC |Local Computer | Certificate Snap-in.

9.19  If you see a private key associated with the public key, you have installed the cert successfully.

Note: If it complains about missing the thumbprint, then manually import the .PEM file into the Local Computer | Personal Certificate snap-in in the mmc. Then double-click the cert and copy the thumbprint from the details tab into the APNS Certificate thumbprint field in the SMP.

10.  Install the APNS Cert on the SMP

10.1  Login to the SMP.

10.2  Export the Apple cert (including private key) from the SMM SS

10.3 Copy it to the SMP.

10.4 Import it into the SMP MMC Local Computer Account Certificate Snap-in personal folder.(you will need the password you set above)

10.5 Click on Home | Mobile Device Management.

10.6  Click on Settings | iOS Enrollment Settings.

10.7 Click Import button in the Apple Push/mdm Certificate section in the right pane.

10.8  Browse to the Apple cert you exported and copied from the SMM SS.

10.9 Enter the password and click ok.

10.10 You should see the thumbprint appear. xxxxxxxxxxxxxxxxxxx

10.11  Click Save Changes.

11.  Record the SCEP/NDES challenge key

This step will need to be completed by the AD architect before continuing.

11.1  Open Internet Explorer and navigate to http://localhost/certsrv/mscep_admin.

11.2  Copy the Enrollment Challenge password into the clipboard and then paste it into a text document

Note: Seeing “This password can be used multiple times and will not expire” is a result of the registry change made previously and indicates that things are configured properly.

12. Configure SCEP Settings on the SMP

12.1 Login to the SMP.

12.2  Click Home | Mobile Management.

12.3 Expand Settings in the left column.

12.4  Click iOS Settings in the left column.

12.5  Click the yellow star next to Cryptographic credential used for authentication.

12.6  On the screen that pops up, click on SCEP in the left column, then click the yellow star in the right pane.

12.7 Enter the following SCEP server information into the corresponding fields:

Name of the Instance: (can be anything you want)

URL: <url to your SCEP/NDES msscep.dll>

Ex.  http://yourndesserv.dir.jccc.edu/CertSrv/mscep/MSCEP.dll

• Subject name:  CN=<scep username that the service runs under>

• Scroll down to make further changes.
• In the Challenge field, input the Mobile Challenge Password as saved in text document during SCEP setup above.
• Click Save Changes.

13.  Create Root CA Certificate Payload

13.1  Open export the trusted root cert for rc-dc2.

13.2 Add it to the initial payload for tablets via these steps.

13.3 Login to the SMP.

13.4 Click Home | Mobile Management.

13.5 Expand Device Management.

13.6 Click Configuration Editor.

13.7 In the right pane, click Credentials.

13.8 Click the yellow star next in the right pane.

13.9 Click Select cert file…

13.10 Choose the Root CA certificate that you exported earlier.

13.11 Give it a friendly name and then Save it.

14.  Configure SSL Communication for Device to SMM SS

14.1 Login to the SMP.

14.2  Click Home | Mobile Management.

14.3 Expand Settings in the left column.

14.4  Click on Mobile Management Server.

14.5 Click on the server in the right pane.

14.6  Click the pencil.

14.7  Ensure you choose to override server connection info, then checkmark Use https, then enter the EXTERNAL FQDN of your SMM SS and set the port to 443 for SSL.

14.8 Then click OK.

15.  General Enrollment Settings

15.1  Login to the SMP.

15.2  Click Home | Mobile Management.

15.3 Expand Settings in the left column.

15.4  Click General Enrollment Settings.

15.5  Click the plus in the Authentication Settings area and add in your internal domain name as well as your AD server name with port 389 specified, and  then click Verify

15.6  Click OK.

15.7  Click Save changes.

15.8 Checkmark Enable authentication check.  THIS IS IMPORTANT because it will check the logon users against the AD you specified above for whether or not the enrolled username they enter at enrollment time is allowed to enroll or not.  This will keep external people from enrolling their mobile device in your MDM environment.

15.9 You will also need to select Microsoft NDES and enter the password for that user you specified above.  Note: IF you choose to go with Symantec’s cert options, you would choose to Enable Symantec MKI Integration and fill in the respective fields, but we did not.

Additional info and documents that helped me a lot:

1.  Summary

1.1 This document is the next in the series of my experience with the Symantec Management Platform project.  Specifically, this document is part two of two for the Mobile Device Management solution from Symantec.  

1.2 This document details the steps I took to configure the profile encryption and security for the MDM solution in my environment. These steps worked flawlessly (after much trial and error) for me, but should be reviewed with your architect first to ensure they will work for your environment. Most steps will need to be modified based on your requirements for your environment, so please keep that in mind when reading through this article.

1.3  The first part of this series may be found here https://www-secure.symantec.com/connect/articles/how-install-and-configure-mobile-device-management-part-1-2

2.  Create iOS Additional Configuration

2.1 Login to the SMP.

2.2  Click Home | Mobile Management.

2.3 Expand Settings in the left column.

2.4  Click iOS Enrollment.

2.5  In the lower pane under Additional Configurations, click the yellow star and add the SMM SS SSL Cert you created earlier AND add the Root CA Credential you added earlier.

Note:  If you are planning to secure the issuing and signing and encryption of data using profiles (which JCCC is doing) then you will need to closely follow the rest of the document.  Most of the following information was obtained from https://www-secure.symantec.com/connect/articles/ios-profile-security-how-sign-and-encrypt-ios-configuration-profiles

3. Create Signing Certificate

NOTE: We had to make a permission changes on the CA and the template to allow my account to be able to request the web certs for the account that I logged into the SMM SS with when performing these steps.

3.1 On the SMM SS, from IIS Manager, click on the server name in the left pane.

3.2 Double-click Server Certificate in the middle pane.

3.3 On the most right pane, click Create Domain Certificate.

3.4 Enter the common name MDM iOSSigning Cert and fill the rest of required fields and then click Next.

3.5 Select the CA and enter a friendly name for the certificate and then click Finish.

4.  Create Encryption Certificate

4.1 On the SMM SS, from IIS Manager, click on the server name in the left pane.

4.2  Double-click Server Certificate in the middle pane.

4.3 On the most right pane, click Create Domain Certificate.

4.4 Enter the common name MDM iOSEncryption Cert and fill the rest of required field and then click Next.

4.5 Select the CA and enter a friendly name for the certificate then and then click Finish.

5.  Extract CA Certificate

NOTE: These next steps are confusing and most of my issues occurred here, so please read through them and try to best comprehend them before trying them.

5.1 On the SMM SS, click Start | Run.

5.2 Enter mmc and click OK.

5.3 In the MMC console, click File |Add/Remove Snap-in…

5.4 Double click Certificates.

5.5 Choose Computer account.

5.6 Click Next.

5.7 Select Local Computer.

5.8 Click Finish then click OK.

5.9 Expand Console Root | Certificates (Local Computer) | Personal | Certificates.

5.10 Double click the Apple Application Integration certificate.

5.11 Click the Details tab.

5.12 Click Copy to File button.

5.13 Click Next.

5.14 Choose DER encoded binary x.509.

5.15 Click Next.

5.16 Browse and enter a file name to save as.

 Ex. C:\cert\Site103AppleCACert.cer

5.17  Click Next, Finish, and then click OK.

6.  Extract Signing certificate to be placed on iOS devices

6.1  On the SMM SS, open MMC certificates console.

6.2  Under Personal |Certificates, double-click on the signing certificate.

6.3  Click the Details tab.

6.4  Click Copy to File.

6.5  In the Certificate Export Wizard, click Next.

6.6  Choose No, do not export the private key.

6.7  Choose DER encoded binary x.509.

6.8  Click Next.

6.9  Browse and enter a file name to save as.

Ex. C:\cert\Site103sign.cer.

6.10  Click Next, Finish, and then OK.

7.  Extract Encryption certificate to be placed on MDM server

7.1  On the SMM SS, open MMC certificates console

7.2  Under Personal |Certificates, double-click on the encryption certificate.

7.3  Click the Details tab.

7.4  Click Copy to File.

7.5  In the Certificate Export Wizard, click Next.

7.6  Choose No, do not export the private key.

7.7  Choose DER encoded binary x.509.

7.8  Click Next.

7.9  Browse and enter a file name to save as.

Ex. C:\cert\Site103Encrypt.cer

7.10  Click Next, Finish, and then OK.

8.  Extract Signing certificate to be placed on MDM Servers

8.1  On the SMM SS, click Start | Run.

8.2  Enter mmc and click OK.

8.3  In the MMC console, click File |Add/Remove Snap-in…

8.4  Double click Certificates.

8.5  Choose Computer account.

8.6  Click Next.

8.7  Select Local Computer.

8.8  Click Finish then click OK.

8.9  Expand Console Root | Certificates (Local Computer) | Personal | Certificates.

8.10  Double-click the Signing certificate.

8.11  Click the Details tab.

8.12  Click Copy to File.

8.13  In the Certificate Export Wizard, click Next.

8.14  Choose Yes, export the private key.

8.15  Click Next.

8.16  On the next screen, leave the defaults and then click Next.

8.17  Click Next.

8.18  On the next screen, enter the svc-alt password. (xxxxxxx) and then click Next.

8.19  Click Next.

8.20 Browse and enter a file name to save as.

                         Ex.  C:\cert\Site103Sign.pfx.

8.21  Click Next, Finish, and then OK.

9.  Extract Encryption certificate to be placed on iOS devices

9.1  On the SMM SS, click Start | Run.

9.2  Enter mmc and click OK.

9.3  In the MMC console, click File |Add/Remove Snap-in…

9.4  Double click Certificates.

9.5  Choose Computer account.

9.6  Click Next.

9.7  Select Local Computer.

9.8  Click Finish then click OK.

9.9  Expand Console Root | Certificates (Local Computer) | Personal | Certificates.

9.10  Double-click on the Encryption certificate you generated above.

9.11  Click the Details tab.

9.12  Click Copy to File.

9.13  In the Certificate Export Wizard, click Next.

9.14  Choose to Yes, export Private Key.

9.15  Click Next.

9.16  On the next screen, leave the defaults and then click Next.

9.17  Click Next.

9.18  On the next screen, enter the svc-alt password. (xxxx) and then click Next.

9.19 Click Next.

9.20  Browse and enter a file name to save as.

Ex.  C:\cert\Site103Encrypt.pfx

9.21  Click Next, Finish, and then click OK.

10.  Import Signing and encryption certificates to the SMP

Note: For this step, iIt is easiest if they are copied from the SS in the steps above where they were created over to the SMP to import.

10.1  On the SMP, click Start | Run.

10.2  Enter mmc and click OK.

10.3  In the MMC console, click File |Add/Remove Snap-in…

10.4  Double click Certificates.

10.5 Choose Computer account.

10.6 Click Next.

10.7  Select Local Computer.

10.8  Click Finish then click OK.

10.9  Expand Console Root | Certificates (Local Computer) | Personal.

10.10 Right-click on Certificates and select All tasks | Import

10.11 Browse to, and import the 2 Certificates Site103Encrypt.cer and Site103Sign.pfx. You need to enter the password set previously for importing Site103Sign.pfx. (leave all defaults when importing).

10.12  Ensure those certificates appear in the Personal certificate store.

11.  Capture Certificate Thumbprints on the SMP

11.1  On the SMP, click Start | Run.

11.2  Enter mmc and click OK.

11.3  In the MMC console, click File |Add/Remove Snap-in…

11.4  Double click Certificates.

11.5  Choose Computer account.

11.6  Click Next.

11.7  Select Local Computer.

11.8  Click Finish then click OK.

11.9  Expand Console Root | Certificates (Local Computer) | Personal | Certificates.

11.10  Double click the Signing certificate you just imported.

11.11  Click the Details tab.

11.12  Scroll down to the thumbprint.

11.13  Copy the Thumbprint out to a text document and save for later steps. : xx xx xx xx xx xx xx xx xx xx xx xx xx xx

11.14  Double click the Encryption certificate you just imported.

11.15  Click the Details tab.

11.16  Scroll down to the thumbprint.

11.17  Copy the Thumbprint out to a text document and save for later steps.: ‎ xx xx xx xx xx xx xx xx xx xx xx xx xx xx

12.  Adding the Certificates to the payload

12.1  Open the SMP console.

12.2  Click Home |Mobilemanagement

12.3  Click DeviceManagement.

12.4  Click ConfigurationEditor.

12.5  Click Credentials, and then click the yellow star in the right pane.

12.6  Select Certificate.

12.7  Select the Site103AppleCACert.cer that was imported from the SMM SS earlier.

12.8  Type MDM Apple CA Cert for description.

12.9  Click Save Changes.

12.10  Click the yellow star in the right pane again.

12.11  Select Certificate.

12.12  Select the Site103Encrypt.pfx that was imported from the SMM SS earlier.

12.13 Type MDM Encrypt pfx for description.

12.14  Enter the password you set earlier when you exported it.

12.15  Click Save Changes.

12.16  Click the yellow star in the right pane again.

12.17  Select Certificate.

12.18  Select the Site103sign.cer that was imported from the SMM SS earlier.

12.19  Type MDM Sign Cert for description.

12.20  Click Save Changes.

13.  Configure Profile Security on the SMP

13.1  In the SMP Console, click Home | Mobile Management.

13.2  In the left pane, expand Settings and click iOS Enrollment settings.

13.3  Under the Profile Security section, import the appropriate certs and enter the thumbprints.

• Profile signing certificate thumbprint: Site103Sign.cer
• Profile encryption certificate thumbprint: Site103Encrypt.cer
• Profile signing/encryption root certificate thumbprint: Site103AppleCACert.cer

Note: Here is a description of each.

Profile Signing Cert Thumbprint - The thumbprint of the certificate that is used for signing the Mobile Management server personal store that was saved in a text file above.

Profile Encryption Cert Thumbprint - The thumbprint of the certificate that is used for encryption on the Mobile Management server personal store.

Device Signing/Encryption Root Cert Config - The credential payload that contains the root certificate that is placed on devices to complete the certificate chain for the decryption and signing validation certificates.

13.4   Click Save changes.

14.  Enable Signing and Encrypting of profiles

14.1  Click Manage | Policies

14.2  Expand Mobile Management | Mobile Configuration policies.

14.3  Click on All Feeds – All Managed Mobile Devices.

14.4  Checkmark Sign configuration profile to device.

14.5  Checkmark Encrypt configuration profile to device.

14.6  Click Save changes.

Additional document that helped me a lot:

http://www.symantec.com/business/support/index?page=answers&startover=y&question_box=https&product_finder=Mobile+Management&productselectorkey=58302&myclicker.x=-843&myclicker.y=-276

The Connector Solution (Data Connector) is a component of the Symantec Management Platform that lets you transfer data between external data sources and the configuration management database (CMDB). The ability to transfer data lets you leverage the data that already exists in the CMDB or other applications. Data transfers can be scheduled, so updates can be regularly, and automatically made to keep data current. Data Connector supports many data formats: OLEDB, ODBC, LDAP, XML, and CSV. Data Connector transfers data through the use of data source definitions and data transfer rules.

In my example that follows, I will be importing a Microsoft Excel Spreadsheet (.xlsx) using OLEDB as the data source to the CMDB.

Create a Data File (Excel Spreadsheet)

First, a data file must be created populated with values to be imported. It is up to you on how to do this, whether this is manually entered data or data created through an external process. If a data file is to be used, the first row can be the column names, which are not required but are recommended to enable the Import Rule to more easily match up the columns to the data classes. If these are the same names as data classes, the Import Rule will automatically select these during the import. In this example, I will use a Microsoft Excel Spreadsheet of new computers.

Create Data Source for MS Excel Spreadsheet

Now that we have an Excel spreadsheet or data file to be import, create a Data Source to read the Microsoft Excel spreadsheet. The following steps details how to create a new Data Source using the connector:

1.       Copy the MS Excel Spreadsheet you created to the Notification Server.

2.       Open the Symantec Management Console and select Setting -> All Setting -> Notification Server -> Connector

3.       Expanded the Connector container

4.       Right click on the container called Data Sources and select New -> OLEDB Data Source and enter an appropriate name such as “MS Excel Spreadsheet of Computers Data Source”

5.       Select the OLEDB Data Source Type as MS Excel 2007 (*.xlsx). Refer to Figure 2 below.

6.       For the MS Excel file, browse and find the spreadsheet that contains the new computers to be imported. Refer to Figure 2 below.

7.       After the MS Excel file is selected, select the Worksheet name. Refer to Figure 2 below.

8.       Under the Import/Export Options, check the box to Allow Import as shown in Figure 2 below.

9.       Also make sure the Pre-process Import Data is checked.

10.    Click on the View import Data … button to validate that you can read the source spreadsheet (see Figure 3 below)

11.    Click Save Changes to save the Source Import and Close the Data Source.

Create Import/Export Rule to Import Computers

Now that we can read the Excel spreadsheet or data file, we need to create an Import/Export Rule to import the new computer resources into the CMDB using the Microsoft Excel spreadsheet as the data source. The following steps details how to create an import using the connector:

1.       Right click on the Import/Export Rules and select New -> Resource Import Export Rule.

2.       Name the rule as needed such as “Import New Computers from Excel”

3.       The first configuration step is to choose the data source that has been previously defined (as in the steps above). If you used the name of the data source that I chose, the select the data source called “MS Excel Spreadsheet of computers Data source” from the Data Source dropdown menu.

4.       Choose the data source

5.       After selecting the data source the base import rule will appear

6.       To configure the import rule in the section Column Mappings:

a.        For the Resource Type: Select Computer and the page will refresh and all the data classes and association mapping for the computer will appear. These fields will be used to properly configure the imported computer resource. Ensure that computer is picked; in general, do not use a generic or wrong type for a specific type, such as "Asset" instead of "Computer". Many user interface elements, such as drop-down lists, will display a pop-up help window when the mouse is hovered over them.

b.       For the Resource Lookup Key, select Resource Name from the dropdown menu.

c.        The page with refresh showing the Name dropdown menu beside the Resource Lookup Key will appear. Select the Computer Name column from spreadsheet in the dropdown menu.

Note:

The Resource Name field will automatically be set to the Computer Name column in the data file. This will usually need to be set to be the correct column. The "Resource name" drop-down list value is generally automatically set based on the "Resource lookup key" and Name drop-down list values. In some cases this is optional and can be left blank but in general, it is usually best that this is filled out to ensure data is brought in and configured correctly. When this field is automatically set, the user does not need to manually assign a data class for the resource's Name.

d.       In the "Data class mappings" section, set any data classes to match their appropriate columns from the Excel Spreadsheet. If the spreadsheet uses the column names in the first row, and if the column names match data class names, these will automatically be set. For the example notice that the Serial Number is automatically mapped to the Serial Number column in the spreadsheet because they are the same name. If the expected data classes are not present, click on the "Select data classes" link to manually pick and choose these.

e.       In summary, configure the rule using the following setting (see Figure 6 below):

                                                               i.      Resource Type:                    Computer

                                                              ii.      Resource Lookup Key:        Resource Name

                                                            iii.      Name:                                    Computer Name (column from spreadsheet)

                                                            iv.      Removed Assets:                 Left Unchanged in CMDB

                                                              v.      Resource Name:                  Computer Name (column from spreadsheet)

                                                            vi.      Serial Number:                     Serial Number (column from spreadsheet)

7.       Click Save the Changes to the Import Rule

8.       In the Run History section you can test the import rule before executing the real thing. This step is highly recommended. Find and press the Test Rule button. The Test Rule will show you the result. Figure 7 shows the Connector Rule Run Status dialog that will appear when the Test Rule completes. If you want more details click View Log.

9.       The Test Rule run is a very important step to help find and fix errors in the source spreadsheet. The Test Rule can be executed multiple times and each time the log file is saved. Verbose logging is selected by default by can be unchecked.

10.    The Import Rule can be scheduled or run by command by selecting the Run Now button. As in the Test Rule the import will gave you a status of imported machines. When you are ready to import the computers, run the import rule once and check the log for errors.

11.    In the Run History for each occurrence there is a log and can be accessed via the View Log button. It will show a log.

The new computers have been added to the CMDB and the Notification Server. You verify that the computers have been imported into the Notification Server by selecting in Manage -> Computers in the Symantec Management Platform.

Conclusion

The Connector Solution can save an organization hundreds of hours on manually entering data into the CMDB directly and help pull information from a variety of sources. Using a Microsoft Excel Spreadsheet as in this example is just one of many solutions to import new data into the CMDB and Notification Server. 

In NS 7.5 we use filters with static inclusions to deploy specific pieces of licensed software. While this process works well, it presents a challenge when an asset goes from Active to In stock.  Ideally when an asset is marked as in stock we would want to go in and remove it from the filters it was set to be statically included in. The idea behind this is that we wouldn't want the same licensed software to be deployed to the next computer when it was reimaged.

For us, only our asset manager can remove computers from filters. For computers that have only a couple of filters this isn't a problem. For other computers there are many filters that need to have the inclusion removed. This can lead to be a very time consuming process.  The only other option we had was to delete the asset and let it repopulate. This obviously worked, but lead us to loose all of the asset history and we didn.want to do that. 

As a process improvement we have given the rest of IT the ability to mark assets as In stock, Retired, or Disposed for their location.  By giving them this access it has allowed more timely updates of assets. That being said it didn't handle removing them from the filters. To address this I started looking on connect. I found a few articles about people using the asdk to do management tasks like this. I then found a script that had the basis of doing this too. I worked through the script with the documentation installed with the asdk to figure out what it was doing and made several modifications.  

Option Explicit
dim itemmanagement
Dim oCollectionManagement, oItemManagement
Dim itemComputer, allItemNames, NSItemDetails, folders()

Const FILTERFOLDER = "{5fe3c58c-176f-4d50-9797-cf986f81487a}" ' FolderGUID to start searching under
set oitemManagement = CreateObject("Altiris.ASDK.NS.ItemManagement")
Set oCollectionManagement = CreateObject("Altiris.ASDK.NS.CollectionManagement")
oitemManagement.Protocol = "HTTPS"
oitemManagement.Port = "443"
oItemManagement.TargetServer = "smp"'this had to match the ssl cert
oItemManagement.Authenticate()
oCollectionManagement.Protocol = "HTTPS"
oCollectionManagement.Port = "443"
oCollectionManagement.TargetServer = "smp"'again had to match ssl cert name
oCollectionManagement.Authenticate()

itemComputer = "%!ItemGuid!%"

' recursive function going through all Folders and Filters below 
Function recurseCheck(GUID)
  for each NSItemDetails in oItemManagement.GetItemsInFolder(GUID)
    If NSItemDetails.TypeName = "PresentationFolder" Then
      recurseCheck(NSItemDetails.Guid)
    Else
        Call oCollectionManagement.RemoveInclusions(NSItemDetails.Guid, itemComputer)
    Call oCollectionManagement.UpdateCollections(NSItemDetails.Guid)
    End If
  next
End Function

recurseCheck(FILTERFOLDER)

wscript.sleep 1000

For this I created a script that ran against Notificatoin Server. It looks for filters under a specific folder, it then tries to remove the computer from each of the filters it finds under the sub folders. This script is also set to use SSL. the important part was that the hostname of the NS had to match the hostname of the SSL Certificate on the NS itself. The script takes an item guid as input I then created a very simple report that looks like the following

select ParentResourceGuid as ItemGuid from ResourceAssociation 
where ResourceAssociationTypeGuid = '3028166F-C0D6-41D8-9CB7-F64852E0FD01' -- status resourceassociation
and ChildResourceGuid in ('1C139F6C-F210-4002-90D0-4DFAF98D5FA4','492C463B-AFA2-4DD6-AE73-6FD2C7B0E489','485C2F89-2FAF-46F3-9E98-D80116D1022D') -- in stock, retired, disposed statuses
and CreatedDate between CURRENT_TIMESTAMP -1 and CURRENT_TIMESTAMP

This looks for computers that have been set as in stock, retired, or disposed in the last 24 hours.  

Finally, to tie it all together I then created an automation policy to run daily. It runs once for each row in the report. The itemguid from this report gets mapped into the job under the parameters section and passes each one through to the script. 

I hope this helps someone else who has many filter inclusions to clean up as assets change status.

In some environments it is necessary to have the location of the large files that Altiris creates on another hard drive. This was often done by installing the agent to another drive.

The location of where the "space hog" files are kept have changed in 7.5 and now installing the agent to a separate drive does not really help when trying to manage those files.

SMP 7.5 added the options to set Patch files to another location which is nice but you still have your large PCTs and Images to worry about. (Or at least I did)

There are two ways I found that you can store these files on another hard drive.

One is to just move the NSCap folder to your separate drive and then point the NSCap share to that location. (I am not sure if this breaks other things. But I did test it with a PCT and it worked). My concern in doing it this way was that there would be two NSCap locations that are not updating to each other.

The other is to create a Symbolic Link to the separate drive so that the system acts as if it was still in the same location. (This way felt more comfortable to me because I didn't want to break any functions that the SMP might be wanting to carry out that doesn't call the share location)

More info about Symbolic Links here:
http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/

Using Symbolic Link:

This method uses a tool that adds the SymLink options to the right click menu.

• First you need to go here and download both the Microsoft prerequisite and then the Link Shell Extension: http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html#contact
  (you will need to scroll down to the "Download" section, just a page bellow)
   
• You want to copy the NSCap Folder to your separate Drive (I put it in a shared folder).
   
• Then go to Microsoft Management Console (you can type "mmc" into start) and make sure you have the Add-on/Snap-in "Shared Folder". Then find NSCap and right click "Stop Sharing" on it. This is to make sure nothing is pointing to the NSCap Folder and trying to access it.
   
• If you can't stop sharing it from that window add the snap in for "Share and Storage Management" then find it in there are stop sharing it.
   
• You are going to want to stop all SMP services and processes so that nothing is accessing the NSCap Folder (I found that rebooting the server and then quickly renaming it worked for me). You want to rename the old NSCap folder on C: to "NSCap (old)" or something different. (I ended up deleting it later).
   
• Now you want to go to the NSCap location on the separate drive (mine is "E:\Libraries\NSCap") and right click on the NSCap folder and chose "Pick Link Source".
   
• Then go to the Notification Server folder where the NSCap lives on C:\ (C:\Program Files\Altiris\Notification Server) and right click in there and chose "Drop As..." Then click "Symbolic Link".
   
• After that go back to MMC and setup the share to the same location again in "C:\Program Files\Altiris\Notification Server\NSCap". Make sure the name of the share is "NSCap" (it should be by default).

Symbolic Link using Command Line:

This method uses the mklink command in Command Prompt.

• Copy the NSCap Folder to your separate Drive (I put it in a shared folder).
   
• Open Microsoft Management Console (you can type "mmc" into start) and make sure you have the Add-on/Snap-in "Shared Folder". Then find NSCap and right click "Stop Sharing" on it. This is to make sure nothing is pointing to the NSCap Folder and trying to access it.
   
• If you can't stop sharing it from that window add the snap in for "Share and Storage Management" then find it in there are stop sharing it.
   
• You are going to want to stop all SMP services and processes so that nothing is accessing the NSCap Folder (I found that rebooting the server and then quickly renaming it worked for me). You want to rename the old NSCap folder on C: to "NSCap (old)" or something different. (I ended up deleting it later).
   
• Now open an elevated command prompt window.
   
• Type in: mklink /D ["DRIVE:\PATH"]"C:\Program Files\Altiris\Notification Server\NSCap"
  In the [ ] put the Drive letter of your hard drive and then the path to where NSCap is. Include " if you have spaces in your file path.
  Example: mklink /D "E:\Libraries\NSCap""C:\Program Files\Altiris\Notification Server\NSCap"
   
• Execute the command and then close command prompt.
   
• Go back to MMC and setup the share to the same location again in "C:\Program Files\Altiris\Notification Server\NSCap". Make sure the name of the share is "NSCap" (it should be by default).

Not using Symbolic Link:

I have not tested this method a lot. I don't recommendit.

• Copy over the NSCap folder to your separate hard drive.

• Start up the Microsoft Management Console by typing "mmc" into start.

• Add the "Share Folders" and "Share and Storage Management" then click "OK".

• Locate the NSCap share and right click "Stop Sharing".

• Then right click "New Share" and create a share to the location on your separate drive.

Both of these methods worked for me but I am not sure how safe just changing the share location is. That is why I opted for the more complicated SymLink option. I did this on a 2008 R2 test server with a fresh install of SMP 7.5 on it with the DB on a local instance of 2012 Express.

I hope this is helpful.

Patrick

We hope you'll enjoy this document comparing the two currently supported versions of Deployment Solution: 6.9 and 7.5 (7.1 is technically still supported, but has reached EOL status and is not discussed except in passing.  Another version of this document already exists for 7.1 here. ).  An Executive Summary from the doc follows:

There has been significant confusion about these two versions of Deployment Solution (DS).  Version 7.5 of Deployment Solution is intended to be a product upgrade and has been significantly expanded to meet the needs of enterprise customers.  However, Symantec recognizes the need to keep both versions active at this time with recognition of the different market needs each fill.  As of 2014, both products are fully supported and no End of Life (EOL) has been made (though at release of DS 7.5, per normal Symantec practice, versions 7.1 and 7.0 both started the EOL cycle. 

This leaves customers with a very real choice between two product versions that offer essentially the same functionality but differ significantly in execution and features.

Which is right for you?  Should you migrate?  If so, to which version?

Hopefully, this document will help clear that up by discussing things like:

• Understanding the fundamental differences in the two versions.
• Understanding how each version fits in the Symantec Endpoint Management portfolio.
• Knowing the strengths and weaknesses of each version of Deployment Solution.
• Understanding how to migrate from 6.9 to 7.5.
• Understanding how to migrate from 7.5 to 6.9.
• Knowing how to integrate both versions during a migration or longer.

Hope you like it!!

(PS.  More in this series - the upgrade to the Putting it All Together series - are forthcoming!)

Purpose

I had the requirement to create a form with, among many other fields, an email address field.  Rather than use the usual validation model on the button component or a validation model on the output path, I decided to use javascript to implement validation directly on the page, as the user types the email value.  

Caveats

This solution was tested in IE 9, IE 11, and Chrome v 33.  The context menu paste may not register in some browsers/versions, such as IE 11.  "onblur" can be utilized with the same script as below as an additional event to help with this issue, but the script only runs when the cursor leaves the textbox.

Workspace Layout

Components used to prove the concept:

• Form Builder
  • Label
  • TextBox
  • Button
  • ImageComponent x 2

Assumptions

I don't cover the configuration basics here such as input/output variables, field requirements, path connections, etc.

Component Configuration

Configure the Control IDs on the TextBox and 2 ImageComponents.

• TextBox Component ID: EmailAddressText
• ImageComponent 1 Component ID: EmailValid (Green Check)
• ImageComponent 2 Component ID: EmailInvalid (Red X)

Form Configuration

Right-click on the form itself, and Edit Form.  

Select the "Behavior" tab, and add a "Body Custom Events" AttributesKeyValuePair event.

Select the "onload" event, and click the ellipsis for Event Handler.

This is where you'll enter the script for the onload validation.  This step is taken to validate any existing value that the variable has at page load.

The script:

document.getElementById("EmailAddressText").style.textTransform="none";

var y=document.getElementById("EmailAddressText").value;
var atypos=y.indexOf("@");
var dotypos=y.lastIndexOf(".");

if (atypos<1 || dotypos<atypos+2 || dotypos+2>=y.length)
{
document.getElementById("EmailInvalid").style.visibility="visible";
document.getElementById("EmailValid").style.visibility="hidden";
}
else
{
document.getElementById("EmailValid").style.visibility="visible";
document.getElementById("EmailInvalid").style.visibility="hidden";
}

The javascript I'm using is a mash-up result of searching Google, StackOverflow, and limited personal javascript knowledge.  The script first ensures that the textbox does not attempt to capitalize any letters automatically - what the user enters is what is typed in, without any auto-correction or auto-caps.  For some reason the workspace I'm using at the moment, whether it was the browser or the workflow code, was auto-capitalizing letters for me.  The "style.textTransform="none";" ensures that this does not occur.  The script following sets variables for position indices as well as the textbox control we are evaluating.  What this translates to is that the email string must:

• Contain only 1 "@" sign, with the "@" sign not being the first character of the string
• Contain at least 1 "." dot, with 1 dot existing after the "@" sign
• Contain a minimum of 2 characters before the end

Source of the email validation javascript: http://www.w3schools.com/js/js_form_validation.asp

TextBox Configuration

This script must also be included in the textbox component in order to check the string as the user types.

Right-click on the textbox component and click "Edit Component".

In the "Behavior" section of the "Functionality" tab, Add an AttributesKeyValuePair event for "Custom Events".

We will need to add 2 separate events, one for "onpropertychange", and another for "onkeyup".

First we will add the "onpropertychange" event.  This will fire on events such as browser-based autocomplete, right-click and paste, and ctrl-V.

Select the "onpropertychange" event, and click the ellipsis for Event Handler.

This is where you'll enter the script for the onpropertychange validation.

The script:

this.style.textTransform="none";

var x=document.getElementById("EmailAddressText").value;
var atxpos=x.indexOf("@");
var dotxpos=x.lastIndexOf(".");

if (atxpos<1 || dotxpos<atxpos+2 || dotxpos+2>=x.length)
{
document.getElementById("EmailInvalid").style.visibility="visible";
document.getElementById("EmailValid").style.visibility="hidden";
}
else
{
document.getElementById("EmailValid").style.visibility="visible";
document.getElementById("EmailInvalid").style.visibility="hidden";
}

Next we'll add the "onkeyup" event.  This will validate the string after every keypress.

In the "Behavior" section of the "Functionality" tab, Add another AttributesKeyValuePair event for "Custom Events".

Select the "onkeyup" event, and click the ellipsis for Event Handler.

This is where you'll enter the script for the onkeyup validation.  It's the same script we used for the onpropertychange event.

The script:

this.style.textTransform="none";

var x=document.getElementById("EmailAddressText").value;
var atxpos=x.indexOf("@");
var dotxpos=x.lastIndexOf(".");

if (atxpos<1 || dotxpos<atxpos+2 || dotxpos+2>=x.length)
{
document.getElementById("EmailInvalid").style.visibility="visible";
document.getElementById("EmailValid").style.visibility="hidden";
}
else
{
document.getElementById("EmailValid").style.visibility="visible";
document.getElementById("EmailInvalid").style.visibility="hidden";
}

Button Configuration

Now we have to ensure that trying to submit a blank or invalid email address is treated as invalid by the submit button.

Right-click on the button component and "Edit Component".

In the "Behavior" section of the "Functionality" tab, Add an event for "Custom Events".  "AttributesKeyValuePair" is selected automatically.

Select the "onclick" event, and click the ellipsis for Event Handler.

This is where you'll enter the script for the onclick validation.  You can edit the Alert to read however you like.

The script:

var z=document.getElementById("EmailAddressText").value;
var atzpos=z.indexOf("@");
var doszpos=z.lastIndexOf(".");

if (atzpos<1 || dotzpos<atzpos+2 || dotzpos+2>=z.length)
{
alert("Email address invalid.");
return false;
}

Final Steps

After all the script events are complete, lay one image component directly over the other.  Only one can be visible at a given time, so we want the icon to appear to change in-place.  Size the components the way you want and save everything.

Note:  The textbox component should be set to "Optional" for the Submit button's requirements.  There should be a workflow validation model present to enforce proper content entry as well, in the case that the client-side javascript doesn't apply or doesn't function as intended.

Resources

Attached is an example project with this proof of concept illustrated.

Here are some of the most-popular articles about Asset Management Solution and Inventory Solution in SymWise:

Asset Mangement Solution

• How to search a Microsoft SQL database for a data value
• Error "Server Error in '/Altiris/application_name' Application occurs when accessing a specific area in the Symantec Management Platform Console
• Altiris IT Management Suite or Symantec-based Endpoint Management solutions may be affected - Microsoft Update (KB 2661254)
• Error System.Data.SqlClient.SqlException (.Net SqlClient Data Provider): Invalid object name 
• Error "License Count for CMDB/Asset Management Solution has been exceeded. Licenses owned:1, in use:1" occurs when trying to use CMDB or Asset Management
• Issues occur when using duplicate computer names and/or GUIDs
• How to capture a network packet trace using Wireshark
• Altiris 7.0 Planning and Implementation Guide -- v1.2
• Error 1303, "The installer has insufficient privileges to access this directory"
• NOTICE OF END OF STANDARD SUPPORT AND END OF SUPPORT LIFE for Altiris Management Solutions v7.0x & 7.1x components.

Inventory Solution

• Various UNIX commands to gather CPU/Processor information
• What are the command lines to manually install subagents in Altiris 7?
• AeXNSAgent.exe using High CPU while running the Software Discovery and/or Inventory tasks.
• Introduction to Custom Inventory in Notification Server 7.x
• Altiris Licensing - Technical FAQ
• Altiris IT Management Suite or Symantec-based Endpoint Management solutions may be affected - Microsoft Update (KB 2661254)
• How do I change File Formats (Unix / DOS / Mac)?
• About using Altiris client tasks in diagnosing client-side issues
• SMP 7.x Unix, Linux and Mac Agent and Solutions - Installation Files and Command Lines Using Native Packages
• Custom Inventory Overview and Samples

With Windows XP going EOL and having 3000 machines still to upgrade, I was tasked with a process to patch these machines as we are paying for one year patch support. Patch Solution does many things that you do not realize and easily. During my process I had to overcome these obstacles and figure out ways to utilize Software Delivery Solution to deliver patches. Yes that part is easy but what about Reboots, targeting machines that need the patches, IE not inventoried in Add/Remove programs and a few others.  There may be a better way but this is working for me at this moment and in the next month or two I will be going with this process for all XP patching in our company. There may be ways to do this more efficiently but I couldn’t find any other way to do it on a short notice so thought I would share with everyone so if someone else has the need they have something to check out.

Prerequisite:

It is easy to create a dynamic filter for a patch target looking at the AddRemove table for the operating system but Internet Explorer does not show up. First link will take you to setup a custom inventory on getting IE inventoried into your environment.

We do not force reboots or power down machines as we are in a business when Scientists maybe doing a run that takes a day/week or months so an auto reboot would not be considered wise. Currently we utilize Patch Solution to display a message every two hrs if they postpone it. Patch gets the reboot status from Patch Solution installing patches and keeping track of this in Patch tables so I had to figure out a way to identify XP machines needing a reboot after a patch install via SWD which is done in link two.

Custom Inventory for IE Version - https://www-secure.symantec.com/connect/downloads/custom-inventory-ie-version

Custom Inventory for XP Reboot Pending After Manual Patching - https://www-secure.symantec.com/connect/downloads/custom-inventory-xp-reboot-pending-after-manual-patching

Patch Reboot Popup and Force Reboot on OK Push – to be documented soon as it is functioning

Note:

                This Article will utilize MS14-011 for IE8 and MS14-015 for XP for examples. I have already patched using this method so my screenshots will not show any targets. Upon next month cycle I will update this with current month targets for reference.

Software Patch KB in Software Catalog

Import in your software into the Software Catalog and setup switches

Filters:

Patch Solution targeted and distributed by the IS Assessment so now we need a way to target machine. I prefer to do dynamic filters so you set it and forget it. I used SQL code in NS6 and it works in NS7 so I utilize that format.

You need to just have the KB number and modify the following SQL:

select Guid from vResource where ResourceTypeGuid in
(select ResourceTypeGuid from ResourceTypeHierarchy
where BaseResourceTypeGuid='493435f7-3b17-4c4c-b07f-c23e7ab7781f')
and GUID IN
(
select t1._ResourceGuid
from inv_aex_os_Internet_Explorer t0
                join Inv_AeX_AC_Identification t1 on t0._ResourceGuid = t1._ResourceGuid
Where t0.Version like '8.%' and t1.[OS Name] like '%xp%'
and t1.[_ResourceGuid] NOT IN
(
select t1._ResourceGuid
from [Inv_AddRemoveProgram] t1
where t1.DisplayName like '%(KB2909210)%'))

XP was easier as you target the canned filter Windows XP Computers

Policies:

This will take place of the Default Software Update Plug-in Policy. We currently utilize 2 cloned copies of Default Software Update Plug-in Policy to target our pilot group and servers leaving the default policy to target our remaining enterprise. Thus you can do one of two things with policies. You can create a policy to target each environment or manually edit each policy after your deployment phase. I can tell you first hand that when I started where I am not they had me setup each patch as an individual patch then edit the policy and add each group after the other finished. I had one month where we had 8 patches x 4 distribution groups means 8x4=32 edits. Not to mention you have to remember to go add them in on the dates. I have forgotten some distributions!!!!!

I will be creating 3 policies for each patch. 2 of them target specific filters and will be filtered at the policy level where the enterprise deployment will target the dynamic filter. Here is the setup for the dynamic policy.

That is it... Nice and Easy!

Hope that helps you with patching your XP systems outside of Patch Solution!

Introduction

Inventory Solution provides hardware and software details on devices in your environment. Understanding how Inventory works, and how to troubleshoot problems, will give you the confidence needed to report accurate, relevant data. This is essential when managing assets and software licenses in the environment. Know what you have and where you have it. This document strives to provide both an understanding of how Inventory works, and how to troubleshoot problems that may arise, enabling you to succeed.

Table of Contents

Logging
    Server and Client logging
    Inventory Verbose Logging
Inventory Prerequisites
Inventory Solution Plug-in
    32-bit Plugin Failing on 64-bit
        Preparation
        64-bit Component
        Managed Delivery Policy
    Verify Plugin installed
Directory Structure and Files
Component or Association missing
    First Method
    Second Method
    Third Method
Application Metering Plugin

Logging

Logs are wonderful! Both on the server and on the clients, logs will provide data when problems occur. They also give you informational messages about routine procedures. When a problem is occurring getting trace logs will enable you or a Support Rep to much more easily diagnose where the problem is occurring. While standard logging will capture errors, trace logging will provide additional details for both the Server and Client.

Server and Client logging

The following details can be used to enable logging. Because trace logging takes a lot more space, you can also use these details to increase the size of each log, and how many log files are generated before it rolls over and begins overwriting previous logs. In the data below I've only included pertinent data to the troubleshooting process.

In Altiris 7, the Altiris Agent logging is controlled registry values in the registry key:

• HKLM\Software\Altiris\Altiris Agent\Event Logging\LogFile

In Altiris 7, the Notification Server is controlled registry values in the registry key:

• HKLM \Software\Altiris\eXpress\Event Logging\LogFile

The same registry values apply to both Altiris Agent and NS logging.

FilePath: Folder path where the log files will be stored; (String Value)

• Agent defaults:
  &nbsp;&nbsp;&nbsp;&nbsp;Windows XP: C:\Program Files\Altiris\Altiris Agent\Logs\
  &nbsp;&nbsp;&nbsp;&nbsp;Windows 7: C:\Users\Public\Public Documents\Altiris\Altiris Agent\Logs\
• NS defaults:
  &nbsp;&nbsp;&nbsp;&nbsp;Versions 7.0.x: C:\Program Files\Altiris\Notification Server\Logs\
  &nbsp;&nbsp;&nbsp;&nbsp;Versions 7.1.x: C:\ProgramData\Symantec\SMP\Logs\

MaxFiles: Maximum number of log files to create; (DWORD Value)

• Agent default: 10 (files)

MaxSize: Maximum size of each log file (in KB); (DWORD Value)

• Agent default: 100 (KB)

Severity: The level of logging to be recorded; (DWORD Value)

• Agent default: value not set, will Error, Warning & Informational messages
• NS default: same as Agent

Additional information:

1. These values can be modified on the client as well as on the server.
2. The NS logging severity level can be set in the Altiris Console In Altiris 7: Settings > All Settings; Notification Server > Notification Server Settings; Logging (tab); The Console will only set the registry value if trace logging level is enabled.
3. When the logs are generated, a.log is always the current log and when the max size is reached, it becomes a1.log. The next one would be a2.log and so on until the max files is reached.
4. Very large log files sizes on the Notification Server can result in poor performance when viewing from the Web console, so you may be better off increasing the MaxFiles rather than the MaxSize.
5. The Agent will not create more than one day of logs regardless of the MaxFiles and PurgeDays settings if the FilePath value is not also specified. This will only be an issue for a 6.0 Agent which was upgraded from NS Client 5.x. NS Client created only the FileName value where the Agent install creates both FileName and FilePath.

There are four main levels of severity logging, and they are:

• Errors
• Warnings
• Information
• Trace

The registry Severity key can be manually adjusted to the desired logging level (these are Decimal values):

1 = Errors
2 = Warnings
3 = Errors and Warnings
4 = Information
5 = Errors & Information
6 = Warnings & Information
7 = Errors, Warning & Information
8 = Trace
9 = Errors and Trace
10 = Warnings and Trace
11 = Errors, Warnings, and Trace
12 = Information and Trace
13 = Errors, Information, and Trace
14 = Warnings, Information, and Trace
15 = Errors, Warnings, Information, and Trace
255 = Verbose logging

Here is an example of a registry increased to trace logging with more files with larger sizes:

Inventory Verbose Logging

This logging is essential when troubleshooting client-side issues with gathering inventory. When used in conjunction with Agent trace logging, a lot of data can be gathered. Verbose logging is enabled per Inventory Policy.

1. In the Symantec Management Console, browse under Manage > Policies.
2. In the left-hand pane, browse under Discovery and Inventory > Inventory > and select the desired policy.
3. Click the Advanced button.
4. Click the Run Options tab.
5. Check the option labeled Enabled verbose client logging.

6. Click OK, and then Save changes to apply verbose logging. Done!
7. NOTE: Only use this for troubleshooting purposes. Turn it off after the desired data has been gathered at the client.

NOTE: If you are gathering verbose logging for the File Scan, the amount of logs required on the client may be great. Each file scanned is logged, so the amount of logging will be vast.

NOTE #2: Remove any inventory not involved in your troubleshooting. For example if the issue is only with the Hardware based inventory, uncheck the options for Software - Windows Add/Remove Programs, File properties, and Server applications. Furthermore, if you know it is only the hardware and not OS-based data classes, go into Advanced, under the data classes tab and uncheck all but the Hardware section. Lastly, if you know the specific data class you are troubleshooting select only that one in the Advanced. This makes it much easier to search through the logs for the desired data.

Inventory Prerequisites

The following items must be met in order for Inventory to function properly. Sometimes it is the lack or inaccuracy of inventory that may alert you to problems with some of these required items. I've included a list of typical symptoms when an item is not functioning properly or is not in good health.

1. Symantec Management Agent installed and working - Obviously, however sometimes it is not known if an agent is unhealthy or not.
   
   1. Symptoms: are inventory not being received or updated from a client.
   2. Problems: include bad install of the SMA, the Client Task Agent is not functional.
   3. Tests: include sending basic inventory, making a config request, and try running another solution policy or task to see if the Client Task Agent is running
2. Inventory Plug-in Installed - Another obvious one, but it does need to be validated.
   
   1. Symptoms: Inventory Policy enabled, SMA working properly, Client not running Inventory
   2. Problems: Filter not updated to install the Agent, Plug-in uninstalled and has not run the install again, Install or Upgrade policies disabled after an upgrade.
   3. Tests: Check to ensure the policy is enabled, check the filter targeted computers to see if the problem system needs the plug-in
3. Inventory License valid - Systems that send in inventory when licenses are exceeded and they do not claim a node will have their inventory thrown out. Expired licenses will have all inventory thrown out and not populated on the server.
   
   1. Symptoms: Inventory gets sent but is not processed at the server, error messages in the logs concerning failed to obtain an Inventory Solution License
   2. Problems: License counts exceed the licensed nodes, also includes if Agentless Inventory is run as those devices also take up Inventory Licenses
   3. Tests: Check the license count. If at the limit or exceeded, delete old computers and devices or obtain a larger license count
4. Good Database Health - Since all inventory is sent and stored in the database, it is essential to have good database health.
   
   1. Symptoms: Inventory is out of date, and not all Inventory being sent up reaches the database.
   2. Problems: Inventory is missing or out of date.
   3. Tests: Check for deadlock messages in the logs. How long are SQL queries taking? If slow, and if deadlock messages, database health may be poor.
5. Good Queue Health - Another one that often goes hand-in-hand with good database health is monitoring the queue to ensure inventory is not overloading it.
   
   1. Symptoms: Symantec Management Console is slow, Inventory is missing or delayed, SQL is overtaxed
   2. Problems: Queue is filled up with Inventory NSEs. Inventory is delayed in processing.
   3. Tests: Check the queue to see if it is filled with NSEs, sample the NSEs to see if they contain inventory data (denoted by data class guid).

Inventory Solution Plug-in

As with most solutions, Inventory Solution requires a plug-in in order to operate. Unlike most other solutions, the Inventory Solution Plug-in does not have a native 64-bit version. At the time this article was written plans are underway to release a 64-bit version. Until that time, it is common to run into an issue where the DLLs used by Inventory are not recognized as valid Win32 applications, thus no data from certain DLLs are captured. The resulting NSE will have a blank DATA section, blanking out any inventory data that might have been captured previously. There is a way around this issue using Software Management.

This section also details how the plug-in is installed on Windows systems. This includes the file structure and what files can be used for troubleshooting.

32-bit Plugin Failing on 64-bit

Using InvSoln.exe allows the data missing from the default policies to be properly captured. The following process creates Managed Delivery Policies to capture inventory, utilizing this client-side Inventory utility. Please note that the full process should be followed to ensure the default policies do not interfere and remove the data again.

Preparation

The following steps create a "dummy" package to be used as an anchor for the delivery policy.

1. Create a directory on the NS with only a simple txt file therein (this will be a dummy package used to utilize the Managed Delivery Policies).
2. In the Symantec Management Console, browse under Manage > Software.
3. Right-click in the Installed Software box in the upper left and select Manage Software Catalog.

IMPORTANT! Please note that it may seem relevant to deviate from these provided steps, however these were create understanding how the different pieces interact. The steps should be followed as listed, and the settings provide should be used as indicated.

64-bit Component

The following resource is created for Inventory Agents installed on 64-bit Windows operating systems.

1. Click Add under Newly discovered / undefined software and choose Software Release.
2. Provide a Name, such as InvSoln.exe Full Inventory.
3. Under version, provide 1.0 (this can be incremented as changes are made, if so desired).
4. In the Company field, type Symantec and choose Symantec from the dropdown.

5. Click on the Package tab.
6. Click Add Package.
7. Provide a name, such as InvSoln Inventory Package, no content.
8. Change the Package Source to Access package from a directory on the Notification Server.
9. Type in the path to the folder previously created, or use the Browse feature to browse to it.
10. Click Display Location, and you should see the name of the text file found within the folder.

11. Click on the Package Server tab.
12. Under the Assign package to: dropdown, select All Package Servers.
13. Click OK to save the Package.
14. Click Add Command.
15. Provide a name, such as InvSoln Full Inventory Execution.
16. Uncheck the requirement "Command line requires a package".
17. Set Installation file type to <other>.
18. Provide the following command line:
    "C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\InvSoln.exe" /fi
19. Repeat the steps for each default Inventory Policy to run, such as:
    "C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\InvSoln.exe" /dhi
    "C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\InvSoln.exe" /dswi
    These cover Full Inventory, Delta Hardware Inventory, and Delta Software Inventory.
20. If you wish to use a custom policy, the command-line must be customized. The following is an example of what it would look like:
    "C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\InvSoln.exe" /i "C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\InvTaskConfig\Name of Custom Policy.xml"
21. Click on the Rules tab.
22. Click *New next to the Applicability Rule dropdown.
23. Provide a name, such as InvSoln 64-bit Applicability.
24. Click the blue + button and choose Registry Key Value.
25. Set the Registry key path: HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Plugin Objects\Agents\InvAgent
26. Set the Registry entry: Install Path
27. Set the Registry value: C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\InvAgent.dll
    NOTE: If a custom install path was chosen, this value may be different.

28. Click OK and OK again to save the Applicability Rule.
29. Click OK to save all changes to the new Software Component.

Managed Delivery Policy

The following steps create a Managed Policy that will properly detect which execution needs to be run so that the proper paths are used based on the platform type.

1. In the Symantec Management Console browse under Manage > Policies.
2. Browse under Software > right-click on Managed Software Delivery > and choose New > Managed Software Delivery.
3. Provide a name, such as: InvSoln Full Inventory Work-around Policy.
4. Under the Policy Rules/Actions, click +Add > Software.
5. Use the upper-right search and look for InvSoln.
6. Locate the 64-bit package created, such as: InvSoln.exe Full Inventory and click OK.
7. Click to highlight the Software Component in the list.
8. Under the Remediation settings section, click the dropdown and choose the command line, such as: InvSoln.exe Full inventory Execution.

NOTE: Ignore the warning displayed.

9. Click the Advanced button.
10. Click the Run tab, and change the Display window: to Hidden.
11. Click OK to save the changes to the Advanced Settings.
12. To Save current progress, click the Save changes button.
13. Expand the Applied to section using the right arrow button.
14. Click Apply to > and choose Computers.
15. Click Add rule under the Filtering Rules section.
16. Use the following settings: THEN: exclude computers not in - Filter - Search for "Windows Computers with Inventory Plug-in.
17. Click Update results to ensure the target is returning the expected number of systems.
18. Click OK to save the target parameters.
19. Expand the Schedule section using the right arrow button.
20. Though no Compliance check will occur, a schedule must be set in the Compliance section. In this case you should set a schedule that fits your infrastructure's needs, such as: Start 18:00 Repeat weekly on Mon.

21. If you wish to have Inventory run immediately the first time, also create a Schedule Time and set it to some time in the past, such as: 01:00, no Repeat (Start date under Advanced is either the same day or a previous date).
22. Leave Remediation to occur immediately.
23. Turn the Policy on, and then click Save changes to put the policy into effect.

Repeat the Policy process to include other Inventory types, such as Delta, Hardware only, custom, etc. The only difference in configuration is what command-line you choose within the Policy, and the name of the policy should be unique and easily recognizable.

Verify Plugin installed

There are several places you can ensure the plugin has been properly installed. Please look through these steps if you need this verified.

1. Check the filter for the Inventory Plugin install
   
   1. In the Symantec Management Console browse under Settings > Agent / Plugins > All Agent Plugins.
   2. Browse under Discovery and Inventory > Windows / UNIX / Linux / Mac > and select Inventory Plug-in Install.
   3. Is this policy enabled? If not, enabled it. If so, expand the Applied to section.
   4. Change the View: to Computers. Review the list of computers in this section. Typically you should have little or no systems in this policy if it is enabled.
   5. If computers are not installing the agent, try adding an extra schedule. Click Add schedule > Scheduled Time and set it for an appropriate time. This will ensure it runs again on any system that might have failed to run the first time.
2. Check on the Server and locally on the Client
   
   1. For the Server, open Resource Manager for the system. On the summary page there is a list of all plugins and agents installed on the system. Ensure it lists the Inventory Plugin.
   2. On the client bring up the Agent UI (double-click on the system tray icon, or launch AeXAgentActivate.exe). Click on the Settings button. In the Agents/Plugins list ensure the Altiris Inventory Agent is listed.

3. Upgrade if necessary
4. Though Inventory will typically work for out-of-date plugin versions, some issues may occur if the plugin version falls behind the version installed at the server.
5. In the Symantec Management Console browse under Settings > Agent / Plugins > All Agent Plugins.
6. Browse under Discovery and Inventory > Windows / UNIX / Linux / Mac > and select Inventory Plug-in Upgrade.
7. Enable this policy if it is not enabled. If needed remove the Run ASAP checkbox and put on a schedule that works with your environment for upgrading agents.

Directory Structure and Files

How the Inventory plugin is installed can be very useful when troubleshooting issues. Many of the files contain inventory data, and others contain methods for how inventory is gathered. By accessing the files on problem systems often the source of the issue can be determined. The two typical install locations are:

• C:\Program Files\Altiris\Altiris Agent\Agents\Inventory Agent
• C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent

If the Symantec Management Agent is installed to a different location, the Inventory Plug-in will also install to that drive/location.

By location, here are files that are useful, and a description of what they contain:

1. C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent - This location contains most of the plugin files that are run when Inventory executes. It is considered the install location of the plugin.
   
   1. InvConfigSln.xml - This file contains WMI, Script, and Registry calls used by various data classes. You can use a data class name to see how that data class is collected.
   2. InvSoftwareScan.xml - This contains data of what will be collected during the file scan.
   3. InvData.mdb - This is an Access database that contains data on the files we have captured via the file scan.
2. C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\InvTaskConfig - This contains specific configurations per Policy of what to capture. It can be used to review what a policy is gathering to ensure updates are making it to the client.
   
   1. Each XML file inside will be specific to the policies, enabled or disabled, defined on the Notification Server.
3. C:\Program Files\Altiris\Inventory\NSI - This contains the NSE fragments for each data class defined in Hardware and Operating System, and Server Inventory. The file names will correspond to the data class. This allows you to review what has been captured for a specific data class. This contains the most recent data. Note that if data does not change with newer scans, these files are not overwritten so the date may be older.
4. C:\Program Files\Altiris\Inventory\Outbox - Files relating to the File Scan are located in this location, namely:
   
   1. AuditPls_diskusage.bak - This contains data summary for number of files and total space taken for selected file types.
   2. AuditPls_filescan.bak - This is the main file containing the data for captured files.
   3. AuditPls_softwarekeyexecutables.bak
   4. AuditPls_summary.bak
   5. AuditPls_deletedfiles.bak - These are files that have been removed from the system, that will thus be removed from the database.
   6. Software Discovery file, typically "CLNINV----.bak" contains data from the Software Discovery run through Inventory Solution.

Component or Association missing

A common issue after an install or upgrade appears when agents are not installing or upgrading their Inventory Plugins. This happens due to a condition where a configuration item gets dropped during the install / upgrade process. This might be the entire package configuration, or an association to it. In the logs the following error or one similar will appear when clients request their configuration:

"2/25/2011 11:01:16 AM","Unable to generate policy XML for item: 8592325b-1b4a-4cf4-8c46-c17a0ba564a2
**CEDUrlStart** :http://entced.symantec.com/entt?product=SMP&version=7.1.6797.0&language=en&module=qlub65YMYgWeGGssRthgvN1WHJjANnIAgZtUStOHQto=&error=862971658&build=**CEDUrlEnd** 
( Exception Details: Altiris.NS.Exceptions.AeXException: Unable to build the client configuration XML for advertisement with guid {8592325b-1b4a-4cf4-8c46-c17a0ba564a2}. Reason: Did not get a row for Software Delivery Advertisement ""Inventory Plug-in - Install"", Guid = {8592325b-1b4a-4cf4-8c46-c17a0ba564a2} from the SWD tables. ---> Altiris.NS.Exceptions.AeXException: Did not get a row for Software Delivery Advertisement ""Inventory Plug-in - Install"", Guid = {8592325b-1b4a-4cf4-8c46-c17a0ba564a2} from the SWD tables.
  at Altiris.NS.StandardItems.SoftwareDelivery.AdvertisementItem.OnBuildClientConfigXml2(Guid workstationGuid, XmlNode requestDocumentElement, XmlTextWriter xmlBuilder)
  --- End of inner exception stack trace ---
  at Altiris.NS.StandardItems.SoftwareDelivery.AdvertisementItem.OnBuildClientConfigXml2(Guid workstationGuid, XmlNode requestDocumentElement, XmlTextWriter xmlBuilder)
  at Altiris.NS.StandardItems.Policies.ClientConfigPolicy.GetConfigXml(Guid resourceGuid, String requestXml)
  at Altiris.NS.AgentManagement.PolicyRequest.<>c__DisplayClass4.<LoadItemPolicy>b__0(IDatabaseContext ctx)
  at Altiris.Database.DatabaseContext`1.PerformWithDeadlockRetryHelper(Int32 retries, Boolean inTransaction, Getter`1 getContext, Action`1 action, Action`1 retry)
  at Altiris.Database.DatabaseContext`1.PerformWithDeadlockRetry(Int32 retries, Boolean startNewTransaction, IsolationLevel isolationLevel, Boolean independentContext, Action`1 action, Action`1 retry)
  at Altiris.Database.DatabaseContext`1.PerformWithDeadlockRetry(Int32 retries, Boolean startNewTransaction, Action`1 action, Action`1 retry)
  at Altiris.NS.ContextManagement.DatabaseContext.PerformWithDeadlockRetry(Int32 retries, Action`1 action, Action`1 retry)
  at Altiris.NS.AgentManagement.PolicyRequest.LoadItemPolicy(String request, Guid requestGuid, Guid resourceGuid, Guid hostGuid, Guid policyGuid, String& policy, String& policyHash, Guid& category, Int32& priority, Boolean& canCache, ISet`1& requiredPermissions, ISet`1& filterCollections) )
( Exception logged from:
  at Altiris.Diagnostics.Logging.EventLog.ReportException(Int32 severity, String strMessage, String category, Exception exception)
  at Altiris.NS.Logging.EventLog.ReportException(Int32 severity, String strMessage, String category, Exception exception)
  at Altiris.NS.AgentManagement.PolicyRequest.LoadItemPolicy(String request, Guid requestGuid, Guid resourceGuid, Guid hostGuid, Guid policyGuid, String& policy, String& policyHash, Guid& category, Int32& priority, Boolean& canCache, ISet`1& requiredPermissions, ISet`1& filterCollections)
  at Altiris.NS.AgentManagement.PolicyRequest.LoadItemPolicies(String request, String configVers, Guid hostGuid, List`1 idents, SortedDictionary`2& policies, SortedDictionary`2& hashes)
  at Altiris.NS.AgentManagement.PolicyRequest.GetPolicies(String request)
  at Altiris.Web.NS.Agent.GetClientPolicies.ProcessRequest(String& request, Byte[]& clientConfigData, String& clientConfigXml, Boolean& compress)
  at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
  at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
  at System.Delegate.DynamicInvokeImpl(Object[] args)
  at Altiris.Common.Threading.LocalThreadPool.InvokeCallback(Object state)
  at Altiris.Common.Threading.LocalThreadPool.ExecuteUserWorkItem(UserWorkItem workItem)
  at Altiris.NS.Threading.NSThreadPool.ExecuteUserWorkItem(UserWorkItem workItem)
  at System.Threading.ExecutionContext.runTryCode(Object userData)
  at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
  at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
  at Altiris.Common.Threading.LocalThreadPool.ExecuteUserWorkItemInContext(UserWorkItem workItem)
  at Altiris.Common.Threading.LocalThreadPool.ThreadPoolProc(Object threadStartParameter)
  at System.Threading.ThreadHelper.ThreadStart(Object obj)
)
( Extra Details: Type=Altiris.NS.Exceptions.AeXException Src=Altiris.NS.StandardItems  Inner Extra Details: Type=Altiris.NS.Exceptions.AeXException Src=Altiris.NS.StandardItems )","Altiris.NS.AgentManagement.PolicyRequest.LoadItemPolicy","w3wp","37"

There are 3 ways to resolve this issue. Each subsequent method involves more work, so it is recommended to go through the easiest first, and only proceed if it does not work.

First Method

This method requires a working environment. Support can supply a working package to complete these steps.

1. In the Symantec Management Console browse under Manage > All Resources.
2. Browse in the right-hand pane under Default > All Resources > Package > Software Package.
3. In the search field in the right-pane, found in the upper right, type: Inventory
4. Find the Inventory Plug-in for Windows Package, right-click, and choose Export.

5. Save the file, and transport it to the Notification Server that is having the issue.
6. At the same location above, right-click on Software Package and select Import.
7. Browse to the file that was copied over in step 5.
8. Done! In many cases this resolves the issue.

Second Method

The second method does not require a working environment, but requires additional steps. It is recommended to take a backup for your database before using the second or third methods to resolve this issue. This is only a precaution, and I have not had issues with these methods in the past.

1. In the Symantec Management Console, browse under Settings > Console > Views.
2. In the left-hand pane browse under Software and select the Software Catalog.
3. In the search field in the right pane, located in the upper right, type Inventory Plug-in
4. In this list, locate all versions for the Inventory Plug-in for Windows.
5. For any entry that shows a disk for the icon (seen in the screenshot for step 10) right-click and choose Delete.
6. Right-click on the resource that contain packages, shown as a different icon, and choose Properties.
7. Copy out the Guid listed for this resource.

8. Run the following query against the database, using the GUID found from step 7.
   UPDATE RM_ResourceSoftware_Release
SET Attributes = '0'
WHERE [Guid] = '80328534-9d5c-4343-bcad-bda7ecf9621f'
9. Reload the Symantec Management Console and browse back to the Software Catalog, using the search filter.
10. Right-click on the Software Resource for the Inventory Plug-in for Windows and choose Delete.

11. Make sure no Inventory (disk) or Release (computer with disk) plug-in items remain.
12. Open a command window (right-click, Run ad Administrator).
13. Browse to the following location where the platform is installed:
    \Program Files\Notification Server\Bin\
14. Now run the following command-line, NOTE that locations will need to be set to your install directories:
    C:\Program Files\Notification Server\Bin\AeXConfig.exe /configure "C:\Program Files\Altiris\Inventory\Config\Inventory.config"
15. To review the progress, open Log View and filter on "AeXConfig". This will allow you to see the entries as the reconfigure is occurring.
16. Done! If this does not resolve the issue, the logs gathered during the reconfiguration are vital.

Third Method

The third method uses a more messy, dramatic approach. It also requires the steps used in the previous approach.

1. Walk through steps 1 through 11 of the Second method.
2. From the logs gathered during steps 12 through 16 of the second method, you'll find an import error. This will include reference to the GUID found in step 8 of the second method. The key to this error is finding the other GUID in the error that causes the import to fail. Once that GUID is found, proceed.
   Message will state: "Unable to import resource (ref), a duplicate resource (ref) already exists"
3. Open the following URL, which is a search query to use: www.symantec.com/docs/HowTo1191
4. Paste the query into SQL Enterprise Manager. Change the GUID to the one found in the message to the location marked /* Enter Search Guid here */

/*
    Last Revision: 3 August 2012
*/

set transaction isolation level read uncommitted

/* Declare variables */
declare @strSql nvarchar(max),
    @searchguid uniqueidentifier,
    @lowrow smallint,
    @SrchEvtTables bit,
    @SrchCharTypes bit,
    @SrchTextTypes bit,
    @CharTypeColName varchar(200) 

/* Enter Search Guid here */
set  @searchguid = ltrim(rtrim('3e71856b-aadb-48d8-8264-0b36d1aac224'))

/* Search Event Tables: If you wish to disable searching the event tables then set 
   @SrchEvtTables to 0.  This option was added since the event tables can get quite large 
   and many of the guid columns in them are not indexed. Disabling this will speed up the 
   query in such cases (at the cost of not searching those tables). 
   (Enabled: 1, Disabled: 0) */
set @SrchEvtTables = 1

/* Search Character Type Columns: There are some columns in the database that hold GUIDs, 
   but the column is not a uniqueidentifier type (they have the GUID as a character string
   instead).  If you want to search character column types (char, nchar, varchar, and nvarchar) then you must set the @SrchCharTypes value to 1.

1. The results may take a minute or longer to complete. The last column contains Select statements. Select the entire column by clicking on the column header, and copy the data.
2. Paste the data into a new query window.
3. Hit Ctrl + H to bring up the find and replace window.
4. Search for: SELECT *
5. Replace with: DELETE
6. Once done, run the query to delete this object from the database's tables.
7. Now run through steps 12 through 15 of the second method.
8. Done!

If the problem persists, please contact Symantec Support for assistance.

Application Metering Plugin

To track usage of applications, and utilize the deny/block functionality for designated executables, the Application Metering Plugin is required. This plugin is only available for Windows Workstations at this time, and does not support Server-class operating systems or Unix, Linux, or Mac.

Please note the following concerning this plugin:

• Stability issues exist - Crashes can occur on 64bit systems. This is often due to the plugin operating through the AeXNSHostSurrogate32.dll process. This process facilitates the plugin running in WOW mode on 64bit systems. Fixes exist for many versions of the plugin, so if you are experiencing crashes please search the knowledgebase or contain Support.
• Resource Utilization - If the Application Metering plugin often begins to cause memory consumption you can restart the Symantec Management Agent service periodically to avoid the issue, It is also recommended you search the KB or contain support for a more permanent solution.
• Do not roll this out to servers. The way the Metering agent monitors all launched processes can cause issues on a server-class system, including crashing the Symantec Management Agent, cause the launching application to fail, or cause other failures of services on the system.

Continue to Part 2: Troubleshooting Inventory Solution 7.5 (also 7.1), Part 2

Introduction

Inventory Solution provides hardware and software details on devices in your environment. Understanding how Inventory works, and how to troubleshoot problems, will give you the confidence needed to report accurate, relevant data. This is essential when managing assets and software licenses in the environment. Know what you have and where you have it. This document strives to provide both an understanding of how Inventory works, and how to troubleshoot problems that may arise, enabling you to succeed.

Table of Contents

Server Components
    Custom Data Classes
    Standalone Inventory Packages
    Application Metering Settings
    Data Classes
Policies versus Tasks
Inventory Policy
    Policy Scheduling
        Default Schedules
        Custom Schedules
        Scheduling Considerations
    Inventory Types
        Hardware and operating system
        Software - Windows Add / Remove Programs
        File Properties
        Server Applications
    Inventory Policy Advanced Run Options
        Delta Inventory
        System Resource Usage
        Throttle Inventory Scan
        Run Inventory User
    Applies To / Compliance
Gather Inventory Task
Inventory Execution Considerations
Identifying the Problem Location
Inventory Process Flow

Server Components

This section covers the Setting and configuration items located in the Symantec Management Console. These are used for administrative and troubleshooting purposes.

Custom Data Classes

To run Custom Inventory, a custom data class to contain the data needs to be created. This is done in the Symantec Management Console under Settings > All Settings > browse in the left-hand pane under Discovery and Inventory, Inventory Solution > and select Manage Custom Data Classes.

Consider the terms as such:

• Data class = Database Table - What is entered will become a table, as in the following example:
  Name entered: My Custom Table
  Resulting Table name: Inv_My_Custom_Table
• Attribute = Database Table Column - Name given the attribute will be the name of the column in the database
• Data type = What type of values are allowed in the column - Make sure you get this one right for the data that is being returned. String works for most values, though data can be manipulated via reporting if it is a specific data type based on the attributes of that data type.
• Size = How many characters are allowed in the field in total - Provide a buffer for expected characters. For example if you believe you'll have about 50 characters, give it a limit of a 100 so data isn't truncated.
• Key = The table requires a unique value from each computer that returns data - This is not typically used for Custom Inventory, but something like Serial Number may be considered Key since it should not have duplicates.
• Required = The table requires data to be returned for the indicated column, so no NULLS are allowed - Only use this if you are sure all computers will return data for this column, because if this value is blank the row will not be added to the database.

In essence, these are details set into a SQL table, but the Platform will require these attributes before it attempts to process data into the database.

NOTE: The biggest item of consideration is to ensure you setup your table correctly the first time. Due to the nature of SQL, making changes after data has been inserted can cause failures based on the existing data. If a change is required, consider the following:

1. Adding a column is not an issue as long as it is not key or does not allow NULLs
2. Changes to existing columns will likely require the table to be truncated first. Custom Inventory would then need to be run again to repopulate the table.
3. Changes to the data class require changes to the Custom Inventory script to account for the change.

Standalone Inventory Packages

These packages are used to gather inventory on systems that are not managed by a Symantec Management Agent. Components of the agent, including Basic Inventory, are contained within the package, including the ability to post to the Notification Server. The page is found in the Symantec Management Console under Settings > All Settings > browse in the left-hand pane under Discovery and Inventory > Inventory Solution > and select Stand-alone Inventory Packages.

When you create the packages, you'll get many of the same options found in an Inventory Task and Policy. Please note the following when creating and using a Stand-alone package:

• The output location specified is, by default, the Notification Server. If this location is not available when Inventory finishes, the data will not make it to the NS and the execution is considered a failure.
• If specifying a local folder, the completed NSEs will be copied and it is then up to the user to get those files to the notification server.
• If specifying a network share, that share must be available when inventory finishes executing as the files will be posted. If it fails to post, the execution is considered a failure.
• The links provided on the page can be sent out to the environment to be clicked and executed automatically.
• Previous to 7.5, a stand-alone package would fail if execute on a system that was managed by the Symantec Management Agent. In 7.5 the execution works just fine.

Application Metering Settings

There is a settings page for Application Metering. The configuration provides a series of purge settings allowing you to control how long data is kept for application metering. This includes events, reports, and summary data. Reach this page in the Symantec Management Console under Settings > All Settings > browse in the left-hand pane under Discovery and Inventory > Inventory Solution > and select Application Metering Configuration.

The default purge settings appear adequate in most environments. If performance becomes an issue, the purge window can be made smaller, allowing reports to run faster. If a longer period of data is required, the values can be increased to account for this. In larger environments performance may be impacted by any increase in the time frames. Another factor is how many applications or EXEs are being metered. The more metered the more data the database will have to handle.

Data Classes

Due to the nature of Inventory, data classes are key to the entire Inventory process. Data classes are basically tables with inventory data inserted into them. The Notification Server uses the data class definitions to manage the tables, mostly when data is to be inserted into them.

To view data class definitions browse in the Symantec Management Console under Settings > All Settings > browse in the left-hand pane under Notification Server > Resource and Data Class Settings > Data Classes. For Inventory expand the Inventory folder. The following list provides feedback on how this section of the console can be used.

1. In the Custom folder all custom inventory data class you have created can be found.
2. When selecting a data class, a summary page appears providing feedback on that data class.
   
   1. Data table name - You can use this to see the exact table name if you are not sure
   2. Guid - Knowing a data class's GUID can be useful when working in auxiliary tables, such as ResourceUpdateSummary.
   3. Multi-rowed - This lets you know if a resource can insert more than one row into the table. Most Inventory data classes are multi-rowed.
   4. Number of resources reported data - This lets you know how many computers have reported inventory for this data class. Good for checking health on data with in a class.
   5. Last reported data - Useful for checking if inventory is being inserted. Note that it does not mean inventory hasn't come in, just for the last time changed or new inventory reached the database to be inserted.
   6. Attributes - This gives you the columns and their data types, including if they are key or not. The default is non key and allow nulls unless otherwise listed.
3. For custom data classes you can delete data classes from this location (right-click, delete).
4. You can export a data class to import at another Notification Server, if so desired (right-click, export).

Policies versus Tasks

Both policies and tasks have their pros and cons. I recommend using Policies for most use-cases, but there may be times when a Task is the right choice to be used. The following table provides the pros and cons for each type.

Highlights for a Policy - With a policy you can enable and then let it go. Clients will get the policy and run it per the schedule regardless of connection state. For a situation where data is needed immediately, a policy may take time to propagate down and return data. Policies cannot be added to a Managed Delivery from Software Management.

Highlights for a Task - Computers must be online at the scheduled time or they will not run it. For situations where data is needed immediately, tasks will very quickly run on active computers. Tasks can also be added as part of a Managed Delivery policy.

An example of a Managed Delivery Policy running Inventory was provided in the section 32-bit Plugin failing on 64-bit. This gives you more capabilities per what a Managed Policy can do.

Inventory Policy

This section will cover most options and advanced options relating to running Inventory. The Policy will be the main focus as opposed to viewing a Gather Inventory Task.

Policies offer the best option for most Inventory scenarios. Once a policy is setup, clients will download their client configuration XML to obtain the policies, and will thus have it ready to execute on the client when the scheduled time arrives, regardless of what connection state the system is in. Note that Inventory Policies ignore Maintenance Windows due to the nature of inventory capture. Each section here covers areas of the Policy configuration.

Policy Scheduling

Scheduling is an important part of Inventory Solution. To ensure Inventory remains relevant and up-to-date, how policies are scheduled should take careful consideration.

Default Schedules

Each Inventory Policy has 3 default schedules that can be used. The default schedules execute at 6:00pm (18:00 military time). The Weekly schedule executes on Monday, and the Monthly schedules executes on the first Monday of every month. Note the following items concerning these default schedules:

• If a computer misses the scheduled time, it will execute as soon as possible afterwards.
• There is an ASAP function built into the schedules. The first time a computer receives the policy, regardless if it is a designated day or time, it will execute the policy.
• Default is Agent time for these times.

Custom Schedules

A custom schedule changes the rules. These schedules are determined by the user when Custom schedule is selected. The Custom schedule is also a hyperlink that opens the page to create and edit the schedules associated with the policy.

Note the following items when using a custom schedule:

• If a computer misses the scheduled time, it will execute as soon as possible afterward unless the Advanced option "Only run at the exact scheduled time" is checked. Also note that if the policy is added to the queue at the scheduled time, it may not execute until later if other jobs are being run. For Inventory, it is not advised to use the exact scheduled time option as it will create the possibility of missing a scheduled inventory run.
• Reoccurring schedules (one with a repeat selected) do not have an ASAP function built in. This means if a monthly schedule arrives at the client the day after the scheduled time, it will wait until the next month to run inventory. To avoid this, a run once schedule with no repeat should be created. The start date in the Advanced options should be set in the past. This way when a client first gets the policy, the client will see it is after the scheduled time and run it immediately. The screenshot above shows how the two schedules can be configured to act this way.
• The Start date should be the day the policy is enabled or earlier. For Inventory it does not make sense to use an End date unless this is a special policy you only want to run for a limited duration.
• Most of the Advanced options should be left as they are when the policy is created.

Scheduling Considerations

For most schedules another major factor to consider is how other Inventory policies are scheduled. There are considerations that must be taken into account to avoid bad inventory integrity. Please review these when setting up your Inventory Solution schedules.

1. Full Inventory - Should be scheduled often enough to avoid out-of-sync issues. The default is weekly due to issues encountered where inventory would not be in sync from client to server. In many instances a full inventory capture will resolve these issues. Full Inventory should at least be run Monthly.
2. Client-Server integrity - One current limitation with how inventory works is a lack of confirmation or validation from the client to server, and vice-versa. The client keeps track of what Inventory it has sent, but has no way to validate if the server received it, or if that inventory has been lost in some way on the server. At the same time the server keeps track of what data it has inserted into the database, which may not match what the client thinks it has sent. The following list include ways inventory can get out of sync:
   1. Computers merged - The merging process can delete inventory data from a record. Only one record's inventory is kept.
   2. Duplicate Guids - If a system shares a GUID with another, inventory is overwritten at the server, so the inventory will be inaccurate or nonexistent when the duplicate issue is resolved.
   3. Computer record deleted from the database - Through Purging Maintenance or a deliberate delete action a record's inventory is deleted. Once deleted, the computer can be added again, but that inventory is now gone.
   4. Data deleted from tables - without a deletion or update to the ResourceUpdateSummary table. This table contains a hash-check. The data sent from the client includes a hash that the server will compare to what is in the ResourceUpdateSummary table. If they match, that data is not inserted into the database. At this point the server does not check to see if the data is actually in the table or not.

   The first 3 issues are resolved when a full inventory is run. The 4th one requires additional work to resolve (covered in the troubleshooting section).

3. Schedule Overlap - Inventory has intelligence to avoid capturing inventory simultaneously for two policies. Each time a policy executes, it checks to see if another inventory thread is running. If so, it puts its own thread to sleep and waits for the first one to finish. This can be avoided, and should be. Consider the following when scheduling multiple inventory policies:
   1. Do no schedule different Inventory Policies to run on the same day.
   2. Account for the weekend where systems are typically turned off so multiple policies don't execute Monday morning.
   3. Judge performance to see how often inventory should be running in the environment. Too aggressive inventory can cause the server to be busy, affecting general and console performance.
4. Delta Inventory - Delta inventories should be limited to specific data points. For example, running a frequent Delta with only the option "Windows Add / Remove Programs..." checked can yield good results in keeping track of what software is being installed. If this included all other data classes, it would send more data each time it ran. By limiting the scope of what is collected, it can be scheduled more often to meet specific requirements, as for software tracking in this example.

Inventory Types

On the main page there are four general Inventory types. Each type may include additional break-down in what is gathered.

How each type works and is configured varies as each has a unique method or properties.

Hardware and operating system

This option contains a myriad of inventory data classes and data points. Under the data classes tab in the Advanced options you see all of the data classes represented by this check box. These Advanced options allow you to select and deselect data classes as needed.

All data classes under the Inventory data classes section apply to the first checkbox, even the Software category. Consider this software category specific for hardware and operating system elements, such as bios data, Fonts, and Anti-virus. Any data class unchecked will not be gathered during the inventory process when the policy executes. This is useful when wanting to capture just certain data and excluding what isn't needed. For example memory can be checked for frequently, with all other options not included so the policy can run frequently, catching any change in memory levels.

The only items not applying to this checkbox is the bottom category: Server Inventory data classes.

Software - Windows Add / Remove Programs

The configuration for this item is simple: Delta or full. This is determined under the Advanced options, under the Run Options tab.

This option does affect the entire policy. The Software checkbox runs the Software Discovery, which is actually a Software Management component. Inventory makes the call to this component to run it, since it falls within Inventory's typical use-cases. Take the following considerations when dealing with this checkbox:

• The largest consideration is that the data returned from this inventory component is large. Typical NSEs of this data is 2000kb, when a full is run. Delta is considerably smaller.
• Verbose Logging does not apply to this option, since the code being run is part of Software Management and not Inventory Solution. For logging on this component, use Agent Trace only.
• Software Resources are created from this, so it is an essential part of the Software lifecycle and should be treated accordingly (run fairly regularly to ensure accuracy). Audits of Software depend on accurate data from this.
• This process also gathers file information for installed software. This means we do get File Resources created and linked to Software Resources at this time.

File Properties

This option has the largest impact on the time it takes for Inventory to complete. Due to the nature of a File Scan, it can take system resources and time to gather and filter all the data. Conversely the amount of File Resources created can be significant depending on how the scan is configured. Please take the following considerations when running the File Scan as part of your Inventory Policies:

1. For System Resource issues, including high CPU or Memory consumption, please use the System resource usage: option in Advanced settings. Low is the default, but Very Low can be selected. Keep in mind that lowering the resource usage will prolong the duration of the Inventory Policy.
2. Only include file types you need. Too many file types will not only bloat the data transmitted up to the Notification Server, it creates many File Resources that can create load or timeout problems for any data selecting from the associated tables.

3. Do not scan network drives by type. Use an include to pinpoint where on the network location you wish to scan. Scanning network locations can cause the following issues:
   
   1. Too much data - if the network location contains a lot of files, like a file server, the results will significantly bloat the file results.
   2. Extended Policy run time - Scanning network locations takes time, significantly in cases where the target has a lot of files. Multiple network shares compounds the problem.
   3. Many clients accessing the network location at the same time can cause the file server to become unavailable or even crash. If the data on the server is vital for business operations, this is a serious issue.
4. Question to ask: Are you using this data? This data is not used to automatically associate files under the File Inventory tab of a Software Resource. Unless you have a specific report you are using on files, this data remains as collected inventory only. If you are not using it, you could consider disabling this option until it is needed.
5. Exclusions override inclusions - If you are including a drive, but want to only scan specific files, adding exclusions will be messy. It is easier to remove the inclusion of the drive, and only add inclusions for the specific locations you want to scan.

Server Applications

This option requires that the Inventory Pack for Servers Plug-in is installed. It is an extension of Inventory for Server-class operating systems, but is not required for standard inventory. The same configuration considerations apply to these data classes as with the Hardware and Operating system ones discussed earlier (in that they can be unchecked to not gather them). If a system does not have the plug-in, these data classes will be skipped when the policy executes. In other words it doesn't hurt to have it checked when targeting both servers and workstations.

Inventory Policy Advanced Run Options

Many of the Advanced options were discussed in the previous section. This section covers those options under the Run Options tab, and expands on what was listed earlier. Some of the Advanced Run Options have significant impact on how the Inventory Policy executes.

Delta Inventory

This option makes a huge difference on what is sent to the Notification Server. If checked, after data is gathered it will be compared to what has already been sent. This is done in the following ways:

• For the Hardware, Operating System, User, and Server Inventory data classes, the data is checked against what is stored in the NSI fragment files. These are located at C:\Program Files\Altiris\Inventory\NSI. If the data is the same, nothing will be sent up to the server for that particular data class.
• File Scan data is gathered, and then checked against what is listed in the InvData.mdb database file, located at C:\Program Files\Altiris\Altiris Agent\Agents\Inventory Agent, or C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent (the drive letter may be different if a different install path was chosen for the Symantec Management Agent). Files not previous recorded are compiled into the NSE, and files that have been removed are compiled in a separate NSE. These are then sent as the delta updates to file data.
• For the Software - Windows Add / Remove Programs option, after the data is gathered it is compared to the softwarecache.xml file, located at C:\Program Files\Altiris\Altiris Agent\Agents\Software Management\Data. Software both added and removed is compiled into a single NSE to be sent to the Notification Server for processing.

System Resource Usage

This option only refers to the File Scan. Low has been found to be sufficient for most environments, and is the default setting. Very Low has been used when impact to targeted machines has been noted. The side-affect is to increase the time it takes for the file scan to run. Hardware, OS, User, Server, and Software inventories are not affected by this setting. An algorithm is used to determine how much CPU is being used by our process, and by other processes. The scan will be throttled back if a system is in heavy use, and will increase resource usage if a system is idle. How throttled or how much utilization to use is determined by the setting. Development did create a chart on what the projected usage is, however due to so many factors it was not published as it is too difficult to predict.

Throttle Inventory Scan

This option provides a much needed tool to avoid both network clogs and Notification Server load balancing issues. The text indicates: Throttle inventory scan evenly over a period of: X hours. The throttling refers to the overall execution of the Policy on all target systems. Not only can network and NS loads be alleviated, virtual environments can avoid stressing the host servers that run the virtual machines. For example if all virtual machines started running a file scan, the I/O on the host server would hit the roof and bring the server down. Please take into consideration the following items when using this feature:

1. When this setting is consulted, the Inventory Policy is already executing according to the client Task state. You'll see the policy executing in the Client Task History. It will remain in this state until it has waited and finally gathered and sent inventory.
2. The clients will use an algorithm to determine how long it will wait to gather inventory with the window provided. For example if 8 hours is chosen, the client will randomly generate a wait time within that timeframe. If 4 hours and 30 minutes is randomly selected, it will wait that amount of time before beginning the gathering process. The law of averages typically spread out the executions to throttle when those clients gather and send inventory.
3. When the gathering is complete the data will be sent to the Notification Server, ending the policy's execution with a success. In the above example if the gathering took 20 minutes, the entire length of the policy execution would be 4 hours and 50 minutes.
4. Since the execution is active during the wait period, if the machine restarts, or the Symantec Management Agent service is stopped or restarted, the execution is then considered a failure when the Agent reloads. When this happens the policy is considered failed and will not retry. Use caution on when policies execute and how long they can wait based on this potential adverse effect.

Run Inventory User

Typically this should be left alone. The System account, and the impersonation it is capable of, provides the access it needs to gather the pertinent inventory. There are a few items that may require this to be changed. For example if you want to gather what drives are mapped, and what shares are open for a user the policy needs to run under the Logged in user. Mapped drives are typically user-based, so this would be required to gather this data properly.

Another example is in situations where the System Account has been locked down. In those cases selecting a specified user that has administrator rights on target systems may be required.

Applies To / Compliance

By default every Inventory Policy, including new ones created, are targeted to the filter: Computers with Inventory Plug-in. The default filter cannot be edited, so it should be deleted and a new one added if you wish to change what systems are targeted.

One useful view is to see how the breakdown is for the Policy per Computer.

In one way this section can be useful is if multiple policies are being created to target different groups of systems. In very large environments this can be done in conjunction with the Throttle Inventory scan setting in order to control how much inventory arrives at any given time. The grouping can be done via OU from an Active Directory Import, or any other designation in individual filters. The key is to schedule different times for identical policies to make the division useful.

Gather Inventory Task

When using a Gather Inventory Task, the Inventory Types and Advanced Options are exactly the same as a policy. The scheduling and applies to sections, however, are different and combined in one place. After Inventory is configured properly, use the Task Status section to schedule or immediately run Inventory. When clicking a New Schedule, you'll get options for when to run it, and on what computers to run it on.

While the interface is different than in the Policy, the main elements are the same. Note that there is not advanced options here, so not all scheduling options will be available in the task.

Override Maintenance Windows should be checked if maintenance windows are in effect. This will ensure inventory will be captured regardless of what restrictions may apply to the target systems. Unlike Policies, clients who are not connected to the Notification Server to get the task may not run it after the server officially expires the task. Since the task is pushed down through the Task Server, it needs to be online to run it.

Computers or filters can be added to the task via the typical targeting Task interface.

Inventory Execution Considerations

To consolidate what has been discussed in the previous sections, this list can be used as a checklist on what to take under consideration when setting up your Inventory Policies:

• Resource Utilization - on local systems, on the network, on the Notification Server, and remote file shares
• Randomization of Execution - To alleviate Resource Utilization, the Throttle Inventory Scan setting can be used, and multiple policies with target systems split up between them can be used
• Delta Inventory versus Full - To avoid stale or out-of-sync inventory, be sure to run Full Inventory often enough
• Exclusions versus Inclusions - Remember exclusions override inclusions
• Frequency of Inventory - Balance resource utilization and need for up-to-date inventory in how frequently you schedule policies
• Simultaneous Executions - Avoid scheduling two policies for the same day on target systems

Identifying the Problem Location

The key to fixing Inventory problems is identifying what is causing them in the first place. The difficulty is that a myriad of problems will result in the same basic symptoms:

• Inventory is out of date or stale
• Inventory reports are not accurate - This includes specific data points, such as reporting on Processor only
• Inventory is missing from some to many systems - this may include all inventory, or only specific data

To overcome this problem, the process needs to be understood and then tracked to identify where the issue occurs. The next few sections cover this process and are the bulk of how to troubleshoot Inventory problems. The previous sections setup things to watch out for and provide understanding in how various components work, and what problems and solutions may arise from that. When facing one of the symptoms above, ask the following questions:

1. Is Inventory running on all expected targeted systems?
2. Are the target system's executions successful?
3. Does the data get properly captured by the client?
4. Is the data accurate during the capture?
5. Does the data make it to the Notification Server over the network?
6. Is the data properly inserted into the database?

Each of these questions have items to review, and troubleshooting steps to try. First, understanding the full Process Flow of Inventory will help when walking through these questions.

Inventory Process Flow

The following process flow gives details about what occurs from start to finish for the entire process.

1. Inventory Policy enabled for the Target Filter. This specifies what computers will receive the configured policy. Enough policies should be enabled to cover the requirements of the environment. For this example. The Full will be considered so all appropriate data is gathered.
2. The Resource Membership update occurs (Delta) that lets the NS know to include the policies in the clients configuration.
3. The clients request their updated configuration by hitting the page: http://Servername/Altiris/NS/Agent/GetClientPolicies.aspx. This page may be https if SSL certificates are being used.
4. The server compiles the configuration XML and the client downloads it to C:\Program Files\Altiris\Altiris Agent\Client Policies.
5. If a new Inventory policy exists, the Inventory configuration XMLs are downloaded to C:\Program Files\Altiris\Altiris Agent\Agents\Inventory Agent\InvTaskConfig or C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\InvTaskConfig.
6. The Policy is executed according to the scheduled time.
7. Hardware, Operating System, Users, and Server Inventory Processes place data files (*.nsi) at: C:\Program Files\Altiris\Inventory\NSI when collected. NSEs are generated from these and passed to the Symantec Management Agent.
8. File data and Software Discovery information is compiled in memory and written to C:\Program Files\Altiris\Inventory\Outbox in NSE format. These are then copied out to the Symantec Management AGent
9. After the NSEs are passed off to the Symantec Management Agent, the Agent posts Inventory to the URL: http://servername/altiris/ns/agent/postevent.asp (https if SSL is implemented)
10. The Receiver will move the inventory into the queue to be processed. If the NSE is large enough, it will split the NSE into multiple files as it is received, copied to the C:\ProgramData\Symantec\SMP\EventQueue\Temp folder, then reassembled when all data has been received, at which point it is placed in the queue. The queue is located at: C:\ProgramData\Symantec\SMP\EventQueue\EvtQueue. In 7.1 SP2 and 7.5 the other queues are not used.
11. As the server picks up each NSE to be processed, it consults ResourceUpdateSummary to determine if data really needs to be loaded in the database. It does this by taking the HASH for each Data class and compares it to the stored hash in the ResourceUpdateSummary table. If the hashes match, it simply drops the data and does not insert. If the Hashes are not the same, the Hash in the table is NULL, or no row exists for that computer and data class, then a row is generated based on the new data.
12. Per data class being processed, the Data Loader loads the Inventory into the associated data class table.

Here is a visual representation of this process:

Return to Part 1: Troubleshooting Inventory Solution 7.5 (also 7.1), Part 1

Continue Reading Part 3: Troubleshooting Inventory Solution 7.5 (also 7.1), Part 3

Introduction

Inventory Solution provides hardware and software details on devices in your environment. Understanding how Inventory works, and how to troubleshoot problems, will give you the confidence needed to report accurate, relevant data. This is essential when managing assets and software licenses in the environment. Know what you have and where you have it. This document strives to provide both an understanding of how Inventory works, and how to troubleshoot problems that may arise, enabling you to succeed.

Table of Contents

Data Processing
    Server Logs
        Invalid Characters (not values)
        DateTime
        NULLs
        Deadlocks
        Other
    Duplicate GUIDs
    Data Class Updates
    ResourceUpdateSummary
Stand-Alone Inventory
Agentless Inventory
    Adding MIBs to Agentless Inventory
    Initial Network Discovery
    Device Classification
        Review Classifications
        Setting up Classifications for Unknown Devices
    Repeat Network Discovery
    Managed Resource Criteria
    Agentless Inventory Configuration
        MIB Configuration
        Creating New Data Classes
        Configuring a New Table
        ‘Get Next’ – Understanding the method
    SNMPutilg.exe – Testing against devices
Conclusion

Data Processing

Once the NSE lands in the queue, the transport process is complete. Essentially the Symantec Management Agent has successfully posted the file to the asp page and the data placed in the evtqueue. At this point it is up to the data loader to get the data into the database, but the process it uses isn’t as simply as inserting it directly.

• Check server logs for processing problems, typically “Failed to process NSE”
• Check bad folders, if enabled
• Profiler for tough cases
• Data based on GUID – duplicate GUID problems – HOWTO49693
• Check Data class updates
• ResourceUpdateSummary – Tech199812

Server Logs

When NSEs are processed errors may keep data from being calculated and inserted into the database. These errors will be displayed in the server logs as severity 1 messages. Depending on the error, the issue may be related to the NSE itself, or to conditions within the database, including poor database health. Issues include:

• Invalid Characters within the NSE throw exceptions -
• Incorrect data format for destination database columns in target tables
• NULL sent where no NULLs are allowed
• Deadlocks which cause data inserts to be rolled back and dropped

Invalid Characters (not values) –

The following errors or similar appear in the log when processing inventory NSEs.

Source: Altiris.NS.ResourceManagement.DataClassImporter.LoadInventory_Impl
Description: Failed to load inventory. ['?', hexadecimal value 0x03, is an invalid character. Line 2421, position 62.]

Source: Altiris.NS.StandardItems.Messaging.InventoryCaptureItem.OnMessage_Impl
Description: Failed to process NSE : ( Unhandled exception. Type=Altiris.NS.Exceptions.AeXException Msg=Failed to load inventory. ['?', hexadecimal value 0x03, is an invalid character. Line 2421, position 62.] Src=Altiris.NS
StackTrace=
  at Altiris.NS.ResourceManagement.DataClassImporter.LoadInventory_Impl(XmlReader reader, Boolean bProcessData, Boolean bForceSchemaValidation, Guid resourceGuidOverride)
 at Altiris.NS.ResourceManagement.DataClassImporter.LoadInventory(XmlReader reader, Boolean bProcessData, Boolean bForceSchemaValidation, Guid resourceGuidOverride)
 at Altiris.NS.ResourceManagement.DataClassImporter.LoadInventory(Guid resourceGuid, XmlReader reader)
 at Altiris.NS.StandardItems.Messaging.InventoryCaptureItem.OnMessage_Impl(String message, Boolean useFilename)
Inner exception. Type=System.Xml.XmlException Msg='?', hexadecimal value 0x03, is an invalid character. Line 2421, position 62. Src=System.Xml StackTrace=  at System.Xml.XmlScanner.ScanLiteral()

Source: Altiris.NS.LegacyInterop.ItemMessageDispatcherService.Dispatch
Description: ItemMessageDispatcherService::Dispatch ( Unhandled exception. Type=Altiris.NS.Exceptions.AeXException Msg=Failed to load inventory. ['?', hexadecimal value 0x03, is an invalid character. Line 2421, position 62.] Src=Altiris.NS
StackTrace=
  at Altiris.NS.LegacyInterop.ItemMessageDispatcherService.Dispatch(String message, Boolean useFilename)
Inner exception. Type=System.Xml.XmlException Msg='?', hexadecimal value 0x03, is an invalid character. Line 2421, position 62. Src=System.Xml StackTrace=  at System.Xml.XmlScanner.ScanLiteral()

Source: Altiris.NS.ClientMessaging.FileDispatcher.ProcessFileCallback
Description: An XmlException occured while processing the message D:\Program Files\Altiris\Notification Server\NSCap\EvtQueue\Process\nseD638.tmp. Replacing invalid characters and re-processing.

Source: Altiris.NS.ClientMessaging.FileDispatcher.ProcessFileCallback
Description: 1 invalid characters were replaced with the ? character.

Cause

The cause for this is simple there is a character in an XML file that we are not able to process. This can be because it is a reserved character for XML, it is a corrupt character that cannot be read or it could possibly be a space in a location that causes the XML to look invalid.

Solution

This warning message does not indicate a problem with the Notification Server or Altiris Agent. Because Notification Server is designed to replace the invalid characters with a ? then process the file again, there is rarely a problem with the file being processed.

If you wish to find out which computers and data classes are sending the events with the invalid character, you can query the data base Inventory classes for entries with question marks (?) in them.

See http://www.symantec.com/docs/HOWTO3916 for a stored procedure that will allow searching of the entire database for a ?

There will be several locations in the database that contain a question mark the one that is most likely of concern would be in one of the Inv_ tables. Even in these tables there could be valid question marks such as in a URL. Look for the ones that seem out of place.

DateTime

DateTime errors crop up occasionally. This occurs when a DateTime value does not adhere to the DateTime value supported by the Notification Server, or the column within the database. An example is shown below:

Invalid column [<column>] value [<Date>] (fixed [[NULL()]]) for resource <GUID>: 'SW Patch Windows' (<GUID>)
Process: AeXSvc (7308), Thread ID: 4, Module: AeXSVC.exe
Priority: 2, Source: DataClassRowCollection.SetColumn

Typically this occurs when an application is inventoried that might have a DateTime value that is from another Country that is different than standard US. If the OS is a different language, this can also occur. Check the knowledgebase for possible solutions. Often the loss is a row from Inventory, though other inventory should process OK despite this error.

NULLs

Another similar issue occurs when a NULL value is presented to the database when no NULL value is allowed. The symptoms caused by this are simply that data is dropped from being processed. Restriction on NULL values is intelligent, so data sent in this format should not be processed into the database. These are more rare than previously since improvements to the process have eliminated the sending of these NSEs, and less database columns hold this restriction.

Deadlocks

When the database is busy, or one process steps on another database process, Deadlocks can occur. General database health will improve avoidance of deadlocks. The difficulty with deadlock issues is that the data discarded or rolled back is not indicated in any logs. The only way to tell if this issue is occurring to Inventory is timing of the errors. The questions to ask are:

1. Do deadlock errors show up when Inventory is scheduled to arrive at the server?
2. Am I missing Inventory that I expect to be there? In other words, is inventory being sent that has no appearance to having made it to the database?
3. Are there many deadlock errors during Inventory processing versus other times when they are rare or do not appear at all?

A Typical deadlock error is generic.

Transaction (Process ID n) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

To help with deadlocks, there are two approaches. One is to track down the deadlock directly. This can be done using help from the following KB article:
http://www.symantec.com/docs/HOWTO7118

The second is to improve SQL performance, either by increasing resources such as RAM, CPU, and Disk I/O, or to use a maintenance plan or other improvements as detailed in the following KB article:
http://www.symantec.com/docs/HOWTO10723

Other

If you see other messages with the text “Failed to Process NSE”, it is advised to search on the extra messaging provided. For example review the following error:

Process: aexsvc.exe (920)
Thread ID: 4996
Module: AltirisNativeHelper.dll
Source: Altiris.NS.StandardItems.Messaging.InventoryCaptureItem.OnMessage_Impl
Description: Failed to process NSE : ( Unhandled exception. Type=System.Xml.XmlException Msg=This is an unexpected token. The expected token is 'NAME'. Line 74, position 1. Src=System.Xml
StackTrace=
  at System.Xml.XmlTextReader.SetAttributeValues()
  at System.Xml.XmlTextReader.ParseElement()
  at System.Xml.XmlTextReader.Read()
  at Altiris.NS.ResourceManagement.LegacyInventoryProcessor.ProcessXmlInventoryNode(XmlNode node, StringWriter classesXmlWriter, Int32 resourceRef)
  at Altiris.NS.ResourceManagement.LegacyInventoryProcessor.ConvertOldStyleInventoryToNew(String oldStyleInventory)
  at Altiris.NS.StandardItems.Messaging.InventoryCaptureItem.OnMessage_Impl(String message, Boolean useFilename) )

Note the message: ( Unhandled exception. Type=System.Xml.XmlException Msg=This is an unexpected token. The expected token is 'NAME'. Line 74, position 1.

You can use this message to search the KB or to derive what may be causing the issue.

Duplicate GUIDs

If data appears to be processing but the record is not updated, this may be due to Duplicate GUID problems.

Useful links and info, found in KB HOWTO49693:

A GUID is shared when two or more Symantec Management Platform (SMP) agents are using the GUID at the same time. This can cause some fairly odd behavior, see:
What are the effects of having duplicate GUID's?
http://www.symantec.com/docs/TECH133462

Preventing Shared GUIDs
How to Prevent Shared GUIDs
http://www.symantec.com/docs/HOWTO93988

Correcting Shared GUIDs
Shared GUID cleanup script
http://www.symantec.com/docs/TECH212345

Detecting Shared GUIDs

To check for shared GUIDs, run the attached SQL query, and review the results; or import the attached Altiris report into the Altiris console, run the report and review the results. The attached Altiris reports is based on the attached SQL query which is based on the query used in the SQL script used TECH212345, mentioned above.

The Altiris report has the additional feature that right-clicking on any row brings up a context menu for the particular Computer GUID.

To confirm whether two or more computers are using the same (shared) GUID, connect to those computers and check the SMP agent's GUID. This can be done using the SMP Agent UI, or using the Remote Altiris Agent Diagnostic (RAAD) tool, see:
Remote Altiris Agent Diagnostics (RAAD) 2.0,
http://www.symantec.com/docs/HOWTO21449

Query results details:

Data Class Updates

To see when data was last processed into a table (not necessarily sent, but when data was actually inserted or updated into the database), you can look in Resource Manager. To do this, follow these instructions.

1. In the Symantec Management Console, browse under Manage > Computers > search for the computer you wish to review, and double-click on its record.
2. Once the new Windows loads, go to View > Inventory (NOTE: Sometimes if you already have a second window open, the Resource Manager will load in that window.)
3. In the middle pane, browse to the data class in question, for example Processor, and select it.
4. When the right-pane loads, click on the Status tab.
5. Review the Data Last Changed field. This is the last time data was inserted in the database. Also note the Data Last Received. This indicates when the Notification Server received inventory for this data class, for this system. If the Notification Server doesn’t think the data is changed, it will not insert it into the database. This leads us to the next section: ResourceUpdateSummary.

ResourceUpdateSummary

When data for a data class gets processed by the data loader, the first matter of business is validating if the data is already in the table or not. This avoids unnecessary inserts if the data is identical, and it a performance measure. Each Inventory-based data class contains a HASH that represents the data. In the table ResourceUpdateSummary that hash is stored, including reference to the Data Class and the Computer. If the hashes match, the data loader drops the data and moves on. If the hashes do not match, the data is inserted or updated in the table.

For the most part this works wonderfully, however there have been times when something causes the hash to not match what is in the table. Possible reasons include:

• Resource Merges
• Merge Scripts or processes
• Purging methods of data
• Direct SQL interactions that include deletes from Inventory tables
• Unknown

Correcting this means to blank out or NULL the data hashes in the ResourceUpdateSummary table.

• Verify that the affected machines are included in the Collect Full Inventory policy filter and that this policy has run on those machines. Also verify that all dataclasses are being collected in the policy.
• This can be checked by navigating to Manage > Policies > Discovery and Inventory > Inventory > Collect Full Inventory and clicking Advanced in the Policy Rules/Actions pane. Dataclasses to be collected should be checked (Hardware, Operating System, User and Group are checked by default in the Full Inventory).
• Run the following query to obtain the GUID of an affected machine. This will be used for testing.
  

  Select * from vComputer
  	Where Name = 'Name of the affected Computer'

• Copy the entry from the Guid column for future use.
• Run the following query to ensure that the GUID is valid and is included in this table. Some fields may still be NULL in the DataHash column while others contain will contain data.
  

  Select * from ResourceUpdateSummary
  	Where ResourceGuid = 'GUID from Step 2'

• Run the following command to delete all entries from the DataHash column for the test computer and reset them to NULL
  

  Delete from ResourceUpdateSummary
  	Where ResourceGuid = 'GUID from Step 2'

• Perform a Full Inventory on the test machine to repopulate the inventory data. All dataclass fields should now contain current and accurate data.

The best way to resolve this on a larger scale is to use the scripts found here:
http://www.symantec.com/docs/TECH202934

Stand-Alone Inventory

Stand-Alone Inventory is useful to gather inventory on devices that are not managed by the Symantec Management Agent. When using this type of inventory, be aware of the following items:

• By default the Stand-Alone process will try to post to the Server URL. If this URL is unavailable during the process the inventory will not be sent, essentially making it a failure. This includes if the server is busy.
• Records created by this Inventory are subject to Purging Maintenance, which can retire or delete computer records.
• Records created by this Inventory consume inventory licenses just like any managed endpoint.
• Stand-alone Inventory Packages (EXEs) should be updated with newer versions when the server is upgraded.
• In version 7.1 a Stand-Alone Inventory could not be run on a system installed with the Symantec Management Agent. In 7.5 this now works without an issue.

Agentless Inventory

This type of Inventory is SNMP network based. Not to be confused with Stand-Alone Inventory, Agentless is primarily meant for network devices.

Adding MIBs to Agentless Inventory

Obtaining updated or adding additional MIBs for Agentless Inventory is necessary for most newer devices. We provide many MIBs by default, but not all our MIBs are the latest, and not all manufacturers or available MIBs are included. Obtaining the MIBs desired is a process of checking with the manufacturers of your network devices. Web sites exist that carry many of the newest MIBs. It is up to the administrator to obtain the MIB files. Once obtained, the following method can be used to add or update MIBs into the MIB library.

Depending on how many MIBs you want to add, the following methods can be used. For one or many MIB file imports, follow these instructions.

1. In the Symantec Management Console, select under Manage > Jobs and Tasks > in the left-hand pane browse to a folder you’d like the MIB import task to reside, for example under System Jobs and Tasks > Discovery and Inventory > Inventory.
2. Right-click on the folder and select New > Task.
3. In the left-hand pane where all task types are listed, look under the Monitoring and Alerting section and select MIB Import.
4. Select the radial for either Import all MIB files, or Import ONE MIB file only. (NOTE: Some versions have issues with the multi-file import. If that is working, you may need to import them one at a time)

5. Click OK to save the Task.
6. Once the Task is saved and appeared in the main console, click the Browse button and browse to the MIB you wish to import.
7. Click the Upload button. You will see the uploaded MIB shown in the task. This is only half the process, so don’t stop now!

8. Click Save changes! Without this step running the task will not upload the MIB. You can tell if this step hasn’t been done if the Save changes button is active.
9. Now click New schedule. Leave it as Now.
10. Click Schedule and let the MIB import. The MIB will now be available for use with Agentless Inventory.

Initial Network Discovery

Once you’ve added the MIBs for devices you know are on your network, no additional configuration items need to be done at this point. Run a Network Discovery using the following method:

1. In the Symantec Management Console, select under Manage > Jobs and Tasks > in the left-hand pane browse to a folder you’d like the Network Discovery task to reside, for example under System Jobs and Tasks > Discovery and Inventory > Inventory.
2. Right-click on the folder and choose New > Task.
3. In the left-hand pane where all task types are listed, look under the Discovery and Inventory section and select Discover Network.
4. Now choose a method to discovery network devices on your network. Note the following items when running Network Discovery:
   • For the most complete results, use the Scan network Devices (ARP) and input the IP Address of a Seed Device (Router, Switch) that has access to the rest of the Network. Generally this device will query other switch/routers for additional device details.
   • You can also use an IP Address range.
   • More than one policy can be created for different segments on the Network.
   • Usually the default settings for scan properties will suffice.
   • Under the Connection profile, please include all applicable Community Strings for your network devices, common delimited. Without the proper strings, Inventory cannot later be collected from devices that do not respond to the provided Strings.
   • To watch the progress of the discovery, in the Symantec Management Console browse under Home > Discovery and Inventory > Network Discovery. In the bottom pane you will see all listed Tasks for Network Discovery, including a Percentage Complete column.

Device Classification

Once you’ve discovered all devices on your network, the next step is to review the data and find what devices have not been correctly classified.

Review Classifications

Follow these steps to review classifications.

1. In the Symantec Management Console, go to Reports > All Reports > browse in the left-hand tree under Discovery and Inventory > and select Discovered Devices by Group.
2. Note that the default date range in the report may not provide all your devices. Make sure you adjust the date so that all Discovery tasks are accounted for.
3. In the pie chart, find the category for Network Resource. Click on that part of the chart to be taken to the Discovered Devices report listing those devices. Another category to look at is Unknown.

4. You can review the Device Name field to figure out what the device is. If you only have an IP Address, this makes it difficult to identify what type of device it is.
5. Further information can be gathered by double-clicking on a row in the report to bring up Resource Manager. If you click under View > Inventory and review the Network Device data class data, you may be able to find more information.
6. Devices that show no SysObject ID are not responding to SNMP and may be computers.
7. If your device is not known and you cannot figure it out by what we gather, it is recommended to manually add the device types you know about in your network.
8. Move on to the next section to add classifications.

Setting up Classifications for Unknown Devices

Use the following method to setup classifications for your devices. Note that before you run an Agentless Inventory you will want to run these steps to make sure your devices are properly setup and classified.

1. In the Symantec Management Console go to Settings > All Settings > browse in the left-hand pane under Discovery and Inventory > SNMP Settings > and select SNMP Device Classifications
2. Click the Add button.
3. Provide the SNMP object ID. Note that if you do not know this, you may have to check with the Manufacturer’s documentation. Each make and model has a specific OID assigned to it in the SNMP tree.
4. Under the Device Type, make sure you choose the correct type. This information will help you properly identify what type of device it will be reported as.
5. Provide the Manufacturer and Device Model for reporting and tracking purposes.
6. The Resource type is essential as this is the type of Resource this device will be created as within the Symantec Management Platform infrastructure. For switches and routers, Infrastructure Device is the appropriate category. These types can be viewed within the Resource Organizational Groups.

7. Click OK when done.
8. Repeat the steps for each make and model you own in the environment. These Classifications are necessary in order to capture Agentless Inventory for these devices. Without a matching classification devices will not pull additional SNMP data through the Inventory for Network Devices Tasks.

Repeat Network Discovery

A Discovery must be run again to properly classify those devices that match the classifications you configured in the above process. It is recommended to rerun all Discover Network tasks you ran previously to have the correct classifications set to them. This step is essential as setting up classifications does not retroactively change devices from Unknown or Network Resource to the new classification. Only running another Discover Network Task will do this.

Managed Resource Criteria

The Primary key can be one of three items captured by the Discovery.

1. NetBios Information: Name.Domain (Note: It must be both halves: the name and domain)
2. MAC Address
3. GUID (assigned by the Notification Server)

If the discovered device doesn't provide the above information, the resource cannot be created into a "Managed" device. NetBios will be used as the primary key if present; otherwise the MAC Address will be used. The following items are also used when creating the resource to avoid potential Resource Device duplication:

• IP Address
• Hostname

Agentless Inventory Configuration

The following process should not be conducted until Network Discovery has been properly configured and run. This process details how to configure Inventory Solution for Network Devices (Agentless Inventory) to capture details on your network.

MIB Configuration

This process can be the most exhausting. Note that the desired MIBs should already have been imported into the system using the method detailed in the previous sections. MIBs can be added later, but it is recommended to have it done previous to this section since adding MIBs that contain the data you need must be imported to complete all the steps in this section.

Creating New Data Classes

The following processes can be used to create additional tables to hold data on SNMP calls you configure. Below are some considerations if you have a lot of data configured, or if you want to ensure you are not duplicating effort.

1. The first thing that must be done before creating a table is to check to see if the OID you wish to map is already mapped in another table. The following query will accomplish this:
   

   SELECT * FROM SNMPOidEntry
   	WHERE oid = ‘<The OID number being queried>’
   		Example: 
   		SELECT * FROM SNMPOidEntry
   		WHERE oid = ‘1.3.6.1.4.1.1991.1.3.27.2’

2. If the above query returns data, you can use the following process to determine where that OID is already being called from.
   Using the above results, take an OID to discover the GUIDs of the tables the OID resides in:

   SELECT DataClassGuid, Oid
   	FROM SNMPTableMap
   	WHERE Oid = ‘<OID taken from step 1 query>’

3. Take the GUIDs from the above query and use the following query to obtain the Table name:
   

   SELECT [Name], Guid
   	FROM Dataclass
   	WHERE Guid = ‘<Guid from step 2 query>’

Configuring a New Table

To add a new table, and thus configure the engine to capture additional SNMP information, use the following process.

1. In the Symantec Management Console go to Settings > All Settings > browse in the left-hand pane under Discovery and Inventory > SNMP Settings > and select SNMP Data Mapping Tables.
2. Click the New button in the upper left of the right-hand pane.
3. Give the table a name (NOTE: For consistency purposes, it is recommended you use SNMP as the prefix to your tables). The name cannot be an existing table name in the Symantec database. Whatever name is provided, the resulting name will be converted as indicated:
   
   1. Name provided: SNMP My Data
   2. Actual table name: Inv_SNMP_My_Data
4. Click the New button under the Table columns section. This is essentially adding columns to your table, and providing details of what to gather via SNMP to put in those columns.

5. Provide a name for the column. This will be the literal column name within the database.
6. Provide the Type. String works for most data. These are data types known to SQL, and specific data types will provide useful functions for queries and other SQL transactions.
7. The Length field needs to be long enough to hold the data captured. If you are uncertain, provide a larger number as a buffer.
8. The Key box typically will not be checked. The table will inherently already have a key field, that of the GUID of the device. Only data that is essentially to be unique to a system, such as the Serial Number, should be marked as Key. This also sets the column to not allow NULLs.
9. Click the hyperlink Select OID to launch the Object ID Selection Tool.

10. Use the mib dropdown to find the MIB you wish to query from. If it is not in the list, you may need to repeat the steps to import the proper MIB.
11. In the object id: section, click on the folders to expand the section. The blue-box items represent OIDs via their names. When you click on one the details will appear in the object details: section. Once the value is found, click the Save changes button to apply the current selection.

12. Note that the Object ID is now displayed. Double-check to ensure this is the value you wish. Consult the manufacturer’s documentation for further guidance, since the name and OIDs themselves do not provide a lot of data on what will be gathered.
13. Repeat the steps for every column required for the table. Note that if there are many desired values, do not put them all in one table. Limit a table to 10 or so columns. This will achieve the following:
    
    1. Helps the Notification Server more easily process the incoming NSEs that contains the captured data
    2. Avoid limits imposed by the Data Loader and SQL on the amount and length of the columns
14. Once complete, Save changes on the table to save our progress.
15. Now click on the Data mappings tab.
16. THIS STEP IS ESSENTIAL! In this list are all the data mappings available. You must select every device type you wish to capture data for this data class. Without any selection, no data will ever make it into this table.
    NOTE: Make sure you apply everything you want, as any Save changes after the initial save will cause the table to be recreated, dumping any data that might already be in it.

‘Get Next’ – Understanding the method

Inventory Solution for Network Devices (Agentless Inventory) uses the ‘Get Next’ call to obtain the value for a supplied OID. This is used to avoid issues with improper responses to a ‘Get’ request. However we use a ‘Walk’ method within the same SNMP branch to traverse for the next value. See the below Examples for clarification.

Example 1 – Next value in the same branch
This example shows the next value that we will return should the supplied OID not provide a response:
1.3.6.1.2.1.4.21.1.8 = No Response → 1.3.6.1.2.1.4.21.1.9 = No Response → 1.3.6.1.2.1.4.21.1.10 = Value.
Note that this value resides in the same branch as the supplied OID. We do capture the value.

Example 2 – Next value not in the same branch This example shows the next value that we will not return should the supplied OID not provide a response:
1.3.6.1.2.1.4.21.1.8 = No Response → 1.3.6.1.2.1.4.21.1.9 = No Response → …1.3.6.1.2.1.4.46.2.1 = Value.
Note that the branch is different, meaning 1.3.6.1.2.1.4.46… does not reside in the 1.3.6.1.2.1.4.21 branch. We will not capture this value.

SNMPutilg.exe – Testing against devices

This utility can be used to test OIDs against a particular device. Other utilities are available that can test SNMP queries. To obtain this utility, access this KB article:
http://www.symantec.com/docs/HOWTO5103

Use the ‘Get’ method to see if the OID you are supplying returns any data. If not, switch to the ‘Get Next’ method to see what the next OID is. If it’s outside of the current branch, Altiris will not capture that OID. You can see what results, and if it’s the value you’re looking for, use the returned OID.

NOTE! Using this utility you need to put a ‘.’ at the beginning of the OID you are querying, and a .0 at the end. This is usually required!

This section only covers the basics for creating new Inventory Solution for Network Devices data classes/Tables. Any added tables should be tested before being rolled out in a Production environment.

Conclusion

This document did not cover UNIX, Linus, and Mac devices, nor any Application Metering functionality that are both part of Inventory Solution. I hope this helps when troubleshooting Inventory Solution issues. Feel free to distribute this document/article as it is provide for use. Note that this document is not provided with any guarantees or implied support, and should be used as a reference resource.

Return to Part 3: Troubleshooting Inventory Solution 7.5 (also 7.1), Part 3

Return to Part 1: Troubleshooting Inventory Solution 7.5 (also 7.1), Part 1

Introduction

Inventory Solution provides hardware and software details on devices in your environment. Understanding how Inventory works, and how to troubleshoot problems, will give you the confidence needed to report accurate, relevant data. This is essential when managing assets and software licenses in the environment. Know what you have and where you have it. This document strives to provide both an understanding of how Inventory works, and how to troubleshoot problems that may arise, enabling you to succeed.

Table of Contents

Target Systems Not Running Inventory
    Does the system have the Plug-in?
    Is the computer part of the target filter for the policies?
    Does a custom schedule have an End Date that's passed?
    Does the schedule only run once?
Execution Fails
    Check Agent UI for status
    Log Errors or Warnings
    Crashes, Restarts, and Hangs
        Crashes, Restarts, Hangs symptoms:
        Remediation:
Data Not Collected
    NSI Files
    Data transmitted to the Server
    Agent Logs
        HTTP Post Errors
    Agent Queue
    Server Logs
        Cause
        Solution
    NSE capture options
    Wireshark

Target Systems Not Running Inventory

If target systems are not running Inventory, here are the questions to ask:

• Does the system have the Plug-in?
• Is the computer part of the target filter for the policies?
• Does a custom schedule have an End Date that's passed?
• Does the schedule only run once?

Does the system have the Plug-in?

This question has two answers that indicate a problem. One is that it does not have the plug-in. The second is it has the plug-in, but it is not running valid scheduled Inventory Policies or Tasks. For the first answer where the plug-in is not installed, please refer to the section Verify Plug-in Install found previously in this article. This section walks through to validate if it is installed or if it is not, and what to do to install it

.

If you find yourself in the situation where the plug-in is installed but inventory is not running, this may indicate a corrupt install of the Plug-in. To resolve this situation, please walk through the following steps:

1. In the Symantec Management Console, browse under Settings > Agents / Plugins > All Agents / Plugins > browse in the left-hand pane under Discovery and Inventory > Windows / UNIX / Linux / Mac, and click on Inventory Plug-in Uninstall.
2. Make sure you delete the current target of the policy, as it is targeted to all systems that have the Inventory Plug-in installed.

3. Use the Apply to > Computers section to add the systems that are having this issue. You can create a filter beforehand or add computers individually in the Target.
4. Typically the Run once ASAP will work the first time you run this policy against systems. If you've used this policy before, you'll need to use the Add schedule > Scheduled Time so systems run this policy again. Also note if you've used a previous schedule, delete the schedule and recreate to ensure it runs against all targeted systems.
5. Enable the policy and Save changes.
6. Wait the sufficient amount of time so all systems have run the uninstall policy.
7. Run a Delta Membership Update to ensure all filters are updated.
8. In the Symantec Management Console browse under Settings > Agents / Plugins > All Agents / Plugins > browse in the left-hand pane under Discovery and Inventory > Windows / UNIX / Linux / Mac, and click on Inventory Plug-in Install.
9. Click on the Apply to row and click the Edit pencil.
10. Click the Update results button. Review the list of returned systems to ensure the right systems show up. If they do not, you may need to wait additional time for the uninstall and filter updates to occur.

11. Likely this will already be enabled, but no specific schedule will be assigned. To get these systems that have previously run it to install, create a new schedule by:
    1. Under the Schedule section, click Add schedule > Scheduled Time.
    2. Provide a time such as 00:10 with no repeat. This schedule should run as soon as systems receive the install policy.
12. Click Save changes.
13. The policy will not run and reinstall the Inventory Plug-in.

Is the computer part of the target filter for the policies?

By default all systems with the Inventory Plug-in are assigned to the three default policies. This ensures systems run Inventory as they should. However not all users use the default policies. When new policies are created, new filters or targets may be applied. I have often come across issues where a client has no enabled Inventory policies based on filter and target settings.

To validate if a computer is part of your Inventory Policies, go through this process.

1. In the Symantec Management Console, browse under Manage > Policies and browse in the left-hand tree under Discovery and Inventory > Inventory > and select one of the enabled policies.
2. Expand the Applies To / Compliance section.
3. In the View: dropdown, select Computers and users.
4. In the search field to the right, type in the name of the computer in question.
5. The system should show up if it is properly applied to this policy, even if it has never run it for whatever reason. If the computer does not show up the filter or target rules excludes this system.
6. To address, change the View: dropdown back to Applied by.
7. Double-click on the row you wish to review. Each row represents a target. Review the rules to see why the computer is not included. Reasons may include:
   1. Computer is part of an exclude filter.
   2. The selected filter for inclusion does not include the computer.
   3. A computer list for exclusion includes the computer.
   4. The computer is not applied as part of a computer list.
8. Repeat the process for each policy as needed.
9. You can either adjust the filter or add the computer to an include computer list to ensure the system or systems are covered.
10. For groups of computers the same steps apply, but the exclusions or inclusions should be viewed in relation to the missing group.

Does a custom schedule have an End Date that's passed?

By default Inventory Policies have no end date to their schedules. If using the default schedules (listed on the policy as Daily, Weekly, and Monthly) no end date will ever be applied. If using a Custom schedule, the end date is not checked by default, however a user can check the end date. Use the following process to determine if an end date is being used, and if so, to correct it. Note that these steps can also be conducted at the same time as the Run Once issue.

1. For each applicable Inventory Policy that is not being run, browse in the Symantec Management Console under Manage > Policies and browse in the left-hand tree under Discovery and Inventory > Inventory > and select the policy.
2. Click on the Custom schedule hyperlink. If one of the default schedules are being used, this is not the cause of the issue.
3. Click the Advanced button.
4. Ensure the End checkbox is not checked. If it is checked, uncheck it. If an end date is required in the future, adjust the end date so it is not past.

5. Click OK, and OK, and save the Policy to apply the changes.
6. Repeat these steps for each policy that is not running.

Does the schedule only run once?

When a schedule is created, a date is not specified unless you go into the advanced settings. Also schedules do not repeat unless a repeat is added. If Inventory is not running as expected, it could be that the schedule applied to the policy only runs once. The following process walks through checking and adjusting the schedule as needed. Note that these steps can also be conducted at the same time as the End Date issue.

1. For each applicable Inventory Policy that is not being run, browse in the Symantec Management Console under Manage > Policies and browse in the left-hand tree under Discovery and Inventory > Inventory > and select the policy.
2. Click on the Custom schedule hyperlink. If one of the default schedules are being used, this is not the cause of the issue.
3. Click the Advanced button.
4. The schedule should have the repeating data included. The below screenshot shows a schedule with repeating executions, and one that will only run once.

5. Add a repeating schedule to at least one of the schedules shown to ensure systems run it regularly to keep Inventory up to date.
6. Repeat these steps for all policies.

Execution Fails

The Applies To / Compliance section will show a percentage of Succeeded versus Failed. For failed executions a number of resources exist to discover what is causing the failure and how to correct it.

• Check Agent UI for status
• Find Error code (typically in the logs at failure point)
• Search KB for specific Error
• Look for explanations in logs around the error
• Use trace and verbose for additional information on what was occurring at failure point
• Crashes/Task Agent Hung

Check Agent UI for status

On The client computer, launch the Symantec Management Agent user interface by double-clicking on the icon in the system tray. If the icon is hidden, launch it by executing AeXAgentActivate.exe found under C:\Program Files\Altiris\Altiris Agent\.

Inventory Policies do not show up under the Software Delivery tab. To check statuses, click on the Task Status tab. Click Task history to review the results of recent Inventory executions.

If the status is Failed, the Return code may provide a specific exit code thrown by Inventory when an exception occurred. If it is 1 or -1, the actual error may only be found in the logs. If you do get a specific error code you can use it to search in the Symantec Knowledgebase for a possible solution.

If the Return code is -1, that is often a restart of the computer system or at least the Symantec Management Agent service. That may indicate an interruption, or a hang of the task. The Start time and End time can be consulted to see how long it ran before being interrupted. You can also check these times to see how long Inventory is running.

Log Errors or Warnings

When there is a failure, often the agent logs will have more data on what occurred. The logs provide the best chance of finding what is occurring and take corrective action. In the very least you can have the error ready if you need to engage support on the issue.

Agent logs are located in different places depending on the version of windows. The Server and Client logging section previous in the article provide locations of where the logs may be. Here is a quick reference:

• C:\Program Files\Altiris\Altiris Agent\Logs\
• C:\Users\Public\Public Documents\Altiris\Altiris Agent\Logs\

The following methods can be used to more easily view the logs and find the necessary messages or errors:

1. In the Task History make a note of when Inventory ran. That time-frame can be used to select only those log files that will contain entries pertaining to the failure.
2. You can enable Diagnostics on the Symantec Management Agent to more easily view the logs using these steps:
   1. Go to Start > Run (or go to Start > and in the search field type "Run" and click OK).
   2. Type "regsvr32" (without quotes) into the Open field and place a trailing space.
   3. Leaving the Run dialog open, use Windows Explorer to browse to C:\Program Files\Altiris\Altiris Agent. Drag the AeXAgentDiagnostics.dll into the Run dialog.
      
   4. Click OK to register the DLL. You should get a message stating: DllRegisterServer in C:\Program Files\Altiris\Altiris Agent\AeXAgentDiagnostics.dll succeeded.
   5. Click OK.
   6. From the Symantec Management Agent system tray icon, right-click and choose Diagnostics Window. This will give you various options, including the first tab labeled Logs. This will allow you to view the logs.
   7. Note that you have to load log files separately to view.
3. If the diagnostics log view is not sufficient, copy the pertinent logs to the Notification Server. Launch the Log Viewer and then clear the log and browse to where you copied the files. This gives you much greater control at reviewing the Agent logs.
4. Be sure to look in the time frame of the execution, especially the End time. The End time should correlate to when the error was thrown.
5. Check the error text. Often it will not be something that is directly actionable. Take the error text (usually the sentence that gives a brief explanation of what happened) and search the Symantec Knowledgebase for possible solutions.
6. Any other entries relating to the Inventory execution can be helpful. Using Log View, you can review entries based on the TID, or Task ID. This may give you what else was being done around the time the error was thrown. If you've enabled Inventory verbose logging, you will have a great deal of information logged before the error, which will likely give a method or data class where the error is occurring.

Crashes, Restarts, and Hangs

When the Symantec Management Agent crashes, or the Inventory Policy hangs, there are no specific log entries that will help to identify this. Instead you have to look at the symptoms to determine if one of these is the case. Review the symptoms and required actions based on your situation.

Crashes, Restarts, Hangs symptoms:

• The Task History shows old Inventory Policies or Tasks as still Running - This might indicate a hang, so you need to determine if the task is indeed active. Check to see if the same task shows another run after the one shown as running. A reboot after the time shown will also indicate it is not really running.
• The Task History shows an Inventory Policy with a failure of -1 - While this might indicate other problems; it sometimes indicates a restart of the Symantec Management Agent service during the execution of Inventory. This kills the thread, and fails the task.
• Multiple Inventory Policies still running - If an Inventory Policy hangs, all subsequently executed policies, including duplicates of the same one, will queue up behind it. Inventory is unique in that it looks for already-running policies and will sleep until its turn arrives.
• A crash might or might not log the policy as failed. Typically the crash will show on the desktop, and a crash event will be logged in the Microsoft Event Viewer. In the least the crash will be captured by Event Viewer.
• A minor crash or exception that halts the policy will log the event in the agent(n).log files. This will show as failed in the Task History and looking up the error in the log provides specifics.

Remediation:

If a crash occurs, check the log and take the error found. This error might point you to a knowledgebase article that provides you with the solution of the issue.

For any hangs, enable verbose logging for Inventory and see what the system is doing. It may be:

• Actually hung - If this is the case see what it was doing before it stopped. This will let you know what part of Inventory is having the issue.
• Scanning files - If the target system has a lot of files, or shortcuts, mapped drives, or file shares it can take a very long time to scan it all.
• Task Server - Client Task Agent may be hung, not Inventory. If Inventory does not log any data about having started in the logs, the problem could be with the Task Agent.

Too many files - If this is the issue and it just scans and scans for days, editing the file scan properties is essential. Under the Inventory types > File properties section there are items to check for to ensure you are not scanning areas you do not want to. Please note the following:

• Including network drives is not recommended unless you are certain those locations will not have excessive files
• Insure that the folder exclusions have not been removed, as this will add many windows-based files to both the scan time and what is gathered.
• Do not include file types like XML that will have many, many files as it will slow down the gathering process, and bloat the data being returned to the NS.
• Exclude folders where many shortcuts may exist to network locations. We found that Inventory scans the files at the end of those shortcuts, or LNK files.

Find the source of the problem - This is essential! There is a method to find out where the issue is occurring. Use the following technique:

1. In the Inventory Policy there are 4 main checkboxes, covered previously in the document. Uncheck all but one and run Inventory. Does the issue happen? If no, uncheck that one and move to the next until the issue occurs. You've now found which type of Inventory is causing the issue.

2. The file properties was covered earlier, but the same principles apply.
3. The options for Software - Windows Add / Remove Programs and UNIX / Linux ? Mac software packages are nonexistent so no settings can be changed. The one file that stores this data is the SoftwareCache.xml. If the issue is occurring at the end of this software scan you can try renaming this file so it is regenerated to see if that corrects the problem.
4. For both options: Hardware and operating system - CPU, hard drives, memory, firmware, users and groups, etc., and Server applications (Requires Inventory Pack for Servers), the following method can be used to pinpoint the exact data class the issue is occurring on.
5. Go into the Advanced settings for the Policy.
6. Under Inventory data classes, check just one of the subcategories.

7. Run Inventory. If the issue occurs, you've found the right category. If the issue does not, uncheck the first and check the next, until you find which one is causing the issue. The same process can be used for the next subcategories, typically platform related. Using this method you will end up with a list of data classes.
8. Select half of the data classes in the list, and run inventory again.

9. If the issue occurs, uncheck half of what you have checked, and run inventory again. Do this until you find the one data class causing the problem. If the issue doesn't occur, select the other half that wasn't selected originally, and use the same process of elimination to pinpoint the problem area.
10. Once you have this information you can:
    
    1. Report the problem to Support with the information on what data class is causing the issue.
    2. Keep that one data class unchecked so that inventory, in all other aspects, will be successful. NOTE: the one data class where that won't work is Logical Device, as this data class ties into many of the other hardware ones.

In the very least completing these processes will give you more information to provide Support if you need to contact them.

Data Not Collected

When Inventory completes successfully, but you do not see the data you expect in the database, there are a number of reasons this might occur. This might be that we are not successfully collecting the specific data you are after, such as the Processor information. In those cases the data section will be blank when going up to the server. It might be we are not attempting to gather it, if the data class is unchecked in the policy being executed. This section covers our failure to collect the data using the methods we use. Considerations include:

• Execution successful but missing data
• Check NSI files for data
• Trace and Verbose logs will log why data is not gathered if NSI data section is blank
• Check Policy selects for data classes
• Check WMI - wbemtest

NSI Files

NSI files contain the data for each data class inventory has been collected for. Most files are kept at this location: C:\Program Files\Altiris\Inventory\NSI.

The following is an example of a NSI file (represented as .bak on the disk):

<inventory>
	<dataClass guid='{9b44bf1b-459e-4d62-ba9d-cdac8c70e8ce}' name='HW Chassis' manufacturer='Altiris' version='1.0' platform='Win32'>
		<data>
			<resource>
<row c2="False"  c5="None" c7="System Enclosure 0" c6="3" c1="1" c8="No Asset Tag"></row>
			</resource>
		</data>
	</dataClass>
</inventory>

The fragment contains the following useful information:

1. Data class name as the name of the file itself
2. Data class GUID and name included
3. Data tags contain the data to be inserted into the database between <data> and </data>.In the corresponding table in the database (data class name in this format: Inv_HW_Chassis), the first column is c0, the second c1, the third c2, and so forth. This is how you can correlate the data in the NSI fragment to the stored data in the database.

If the data is missing, such as having no data in the data tags, then Inventory is unable to pull that information from the computer. When this occurs we can check the source of the information by using the following method:

1. Note the Data class name (this will be the name of the NSI or .bak file found in the NSI directory).
2. Browse to the following location: C:\Program Files (x86)\Altiris\Altiris Agent\Agents\Inventory Agent\.
3. Open the file InvConfigSln.xml in Notepad, Internet Explorer, or another editor such as Crimson Edit or Notepad++.
4. Do a search for the data class name. For example if HW Processor is the data class name, do a search for "HW Processor". You will find a map from the name to the data class GUID, but further down in the document you should find a section for Processor.
5. Now review the data found there.

The difficulty is finding what is being done, however WMI is the largest source of data and most queries can be found by reviewing the data. For this example I will take HW Processor since it has a lot of logic, but the WMI calls can still be found. I've taken a snippet of the Processor section. Please note the highlighted sections below:

<dataClass name="HW Processor" GUID="{23d8740a-1e0e-4372-9986-e35793e36a93}" merge="horizontal"> 
       <approaches>
        <approach type ="script">
         <commands>
          <command scriptType="vbscript" function="execute" timeout="70000">
           <scriptText>
            <![CDATA[
              'function to delete duplicate from array.
              Function removeDupsArray(sList)
			              Dim sNewList, maxItems
			              maxItems = UBound(sList)
			              For x = 0 To maxItems
							If IsEmpty(sList(x)) = False And Len(sList(x)) >= 1 And InStr(sNewList,(sList(x) & ",")) <= 0 Then
									              sNewList = sNewList & sList(x) & ","
						              End If
			              Next
							If Len(sNewList) >= 1 Then 
			              removeDupsArray = Left(sNewList,Len(sNewList)-1)
							End If
              End Function

              ' my original function starts from here
              dim Processor(10)
              dim Strduplicate
              dim NewArr

              Function execute()
	              On Error Resume Next
	              Set objNetwork = CreateObject("Wscript.Network")
	              strComputer = objNetwork.ComputerName

	              dim oVersion
	              oVersion = 0
	              Dim Str, Seps(2) , Version(3), majorVersion , minorVersion
	              Set objWMIService = GetObject("winmgmts:\\"& strComputer & "\root\cimv2")

	              Set wmiOperatingSystems = objWMIService.ExecQuery("Select * from win32_operatingsystem" ,,48)
	              For Each wmiOperatingSystem In wmiOperatingSystems
		              oVersion = wmiOperatingSystem.version
	              Next
		              Str   = oVersion
		              Seps(0) = "."
		              Seps(1) = ","

		              Dim i, a
		              a = Tokenize(Str, Seps)

		              For i=1 to UBound(a)
			              Version(i-1) = a(i-1) 
		              next
		              majorVersion = Version(0)
		              minorVersion = Version(1)
              					
	              if(majorVersion < 6 ) then
	              Set wmiProcessors = objWMIService.ExecQuery("Select * from Win32_processor",,48)
	                k = 0
	                For Each wmiProcessor In wmiProcessors
		               Processor(k) = wmiprocessor.SocketDesignation 
		               k = k + 1
	                Next
	               Strduplicate = removeDupsArray(Processor)
	               NewArr=Split(Strduplicate,",")
	               For a=0 to Ubound(NewArr)
		               
		               Set wmiProcessors1 = objWMIService.ExecQuery("Select * from Win32_processor where socketdesignation ="& "'"& NewArr(a) & "'",,48)
		               j = 0
		               For Each wmiProcessor In wmiProcessors1
			               If(j = 0) Then
				               resultset = resultset & "<row "
				               resultset = resultset & " c0="""& ReplaceIllegalCharacters(wmiprocessor.Family) & """"
				               resultset = resultset & " c1="""& ReplaceIllegalCharacters(wmiprocessor.OtherFamilyDescription) & """"
				               resultset = resultset & " c2="""& ReplaceIllegalCharacters(wmiprocessor.MaxClockSpeed) & """"
                   If (Not (IsNull (wmiprocessor.ExtClock))) then
				               resultset = resultset & " c3 ="""& ReplaceIllegalCharacters(wmiprocessor.ExtClock) & """"	
                   End If
				               resultset = resultset & " c4="""& ReplaceIllegalCharacters(wmiprocessor.AddressWidth) & """"
				               resultset = resultset & " c5="""& ReplaceIllegalCharacters(wmiprocessor.DataWidth) & """"
				               resultset = resultset & " c7="""& ReplaceIllegalCharacters(wmiprocessor.Version) & """"
				               resultset = resultset & " c10="""& ReplaceIllegalCharacters(wmiprocessor.DeviceID) & """"
				               if ( IsNull ( wmiprocessor.NumberOfLogicalProcessors)) then
				               else
					               resultset = resultset & " c8="""& ReplaceIllegalCharacters(wmiprocessor.NumberOfLogicalProcessors) & """"
				               end if 
				               if ( IsNull ( wmiprocessor.NumberOfCores)) then
				               else
					               resultset = resultset & " c9="""& ReplaceIllegalCharacters(wmiprocessor.NumberOfCores) & """"
				               end if 
				               resultset = resultset & "/>"
				               End If				
		               j = j + 1

While there is a lot of organizational code, I can use the above information to check against WMI on the local system. Let's say the Version is missing from the data set. Use the following process to check the version based on the data found in the InvConfigSln.xml.

1. In the NSI file, the value for c7 is missing, as shown in this snippet: <row c6="9" c0="2" c2="1800" c4="64" c5="64" c10="CPU0" c8="1" c9="1"/><row c6="9" c0="2" c2="1800" c4="64" c5="64" c10="CPU1" c8="1" c9="1"/><row c6="9" c0="2" c2="1800" c4="64" c5="64" c10="CPU2" c8="1" c9="1"/><row c6="9" c0="2" c2="1800" c4="64" c5="64" c10="CPU3" c8="1" c9="1"/>
2. Now looking in the InvConfigSln.xml, I found the WMI query used to capture this info. The parts from the above example of the XML file are:
   
   1. Set objWMIService = GetObject("winmgmts:\\"& strComputer & "\root\cimv2")
   2. objWMIService.ExecQuery("Select * from Win32_processor"
   3. c7="""& ReplaceIllegalCharacters(wmiprocessor.Version)
3. Launch Windows WMI utility by going to Start > Run > type wbemtest > and click OK.
4. Click the Connect button.
5. The Namespace was given root\cimv2, so type this into the Namespace area if it is not already set and click Connect.
6. Click the Query button.

7. In the query window, use the XML file, namely: Select * from Win32_processor
8. Click Apply.
9. Double-click on the row returned. If more than one row returned, double-click on one of the rows. Note that in this example we had 4 processors returned, so we have 4 rows. Also note that none of the processors returned a c7 value, or the Version value.
10. In the Properties window, scroll down until you find the property "Version".

11. Note that the value is empty, or blank. A <null> will also not return any data. We have confirmed that WMI does not have a value for this property, thus is why we do not return a value.

This process can be done for any of the data classes as most of them use WMI as a source for data. There are scripts that are also run, and in some instances API calls. These are more difficult to test against without knowledge of how the calls are made.

Data transmitted to the Server

Once Inventory is complete, it hands the resulting NSEs over to the Symantec Management Agent. There are several areas where data can be lost. Initially, the Agent attempts to post the NSE directly to http://servername/altiris/ns/agent/postevent.asp. If this fails, it will place the NSE in the queue. The following list provides points that can be reviewed when tracking if the NSEs made it to the Notification Server queue.

• Agent logs will show if problems with NSE transport
• Check Agent queue C:\Program Files\Altiris\Altiris Agent\Queue
• Check Server logs for NSE transport problems
• Check for busy messages both Server and client-side
• Wireshark for hard cases

Agent Logs

In the agent logs any difficulty sending events or inventory to the Notification Server will be logged. The two most common issues are Server Busy, or the URL is not available (client is offline, for example). Errors include:

• PostFile to 'HTTP://<NSServerName>/ALTIRIS/NS/Agent/PostEvent.asp' failed: HTTP error: 503 Service overloaded (-2147213300)
• Attempt for url http://altiris.hsd1.org/Altiris/NS/Agent/PostEvent.asp returned 2147554187, Post failed, HTTP error: 404
• HTTP error: 403 Forbidden (-2147209951)
• HTTP Request Failed: An unexpected network error occurred. (-2147024837)

The following process provides ways to resolve this error in some instances.

HTTP Post Errors

• Generally HTTP Post errors are caused by either name resolution or security.
• Open up a browser on the client machine. In the log the HTTP Post error will have a corresponding URL, for example:

• http://servername/AeXNS/Postevent.asp Try to reach this site locally from the client machine. You should receive a 'NO DATA' message. If you receive "Page cannot be found" or "Page cannot be displayed", we are failing to reach the site.

Also check for the pages http://servername/AeXNS/getclientpolicies.asp and http://servername/AeXNS/createresource.asp.

When accessing the getclientpolicies.asp you should receive the message:

"<error number="80041002">
- <![CDATA[ Failed to GetClientConfig. Error number: 80041002. Error description: GetClientConfigXml failed: Guid not found in request "<Request></Request>"
 ]]> 
 </error>"

When accessing the createresource.asp you should receive the message:

"- <error number="80004005">
- <![CDATA[ 
Failed to CreateResource. Error number: 80004005. Error description: DataLoader: Failed to CreateResource: XML Parse Error 0xc00ce558 at line=0, pos=0
Reason:
XML document must have a top level element.
Near:
Doc head:
 ]]> 
 </error>"

If you do not receive the above messages, this is likely a security issue.

1. On the Notification Server, open up IIS Manager.
2. Right-click on the Default Website and choose Properties.
3. Select the tab "Directory Security"
4. Click Edit under Authentication and access control.
5. Both Enable anonymous access and Integrated Windows authentication in most cases. For secure environments this may be tightened, but Integrated Windows should be checked.
6. Do the same on getclientpolicies.asp, createresource.asp. and postevent.asp

Other permissions should be set as follows:

1. Users security group should have read permissions (and IUSR_<computername> should be a member of users).
2. Also check the EvtQueue and EvtQFast directories. The Users security group should have read and write permissions (and IUSR_<computername> should be a member of the users group).
3. You can see if the NS client machines are having problems getting to these files by setting the NS server name (FQDN, NetBIOS, IP address) to be in the Restricted Sites IE security zone on one or more of the NS client machines, and then make sure the custom security on this zone is set for User Authentication --> Logon --> Anonymous logon [This makes sure that the connection is anonymous to these pages on the NS server, which is the same as how the NS client does it.] Then in a browser window one of the NS clients machines where the IE security has been configured as above go to the three previously listed ASP pages to see if you get the correct results.
4. User group should have read and write permissions on the NTFS equivalent files and folders corresponding to the anonymous IIS permissions. The AeXNS virtual website is the Notification Server folder.

Agent Queue

The Agent Queue is very useful to hold data that could not be transmitted to the Notification Server. In most instances this works well, and allows data to be transmitted after connection has been reestablished. The queue is located at:

C:\Program Files\Altiris\Altiris Agent\Queue\fqdn_ofservername.domain.com\

Note that the drive letter and install path may be different, and that the last folder will be the fully qualified domain name of the Notification Server.

If Inventory files reside in this queue, typically it means the client cannot reach the server or the server is returning that it is busy. If this occurs, please note the following:

• If there is a connection, then the server is probably busy.
• If there are a lot of files located here, there may be a huge load problem on the Notification Server, or the NS has not been processing files for some time.
• With instances where there are a lot of files, the agent queues should be flushed if this client is an indication of what all clients possess. Run through this process to do it if necessary:
  • The registry key FlushAgentEvents (Reg_Dword located under HKEY_LOCAL_MACHINE > SOFTWARE > Altiris > eXpress > Notification Server) controls the ability to flush the local queue for the Altiris Agent. When set to 1, the Notification Server Event Router will send the Altiris Agent an error response that will activate "flush local queues" on the Altiris Agent side. By default, this value is 0.
  • Note: This registry setting exits only on the Notification Server.
  • If the FlushAgentEvents registery key does not exist on your Notification Server, you can create it. In REGEDIT, click My Computer > HKEY_LOCAL_MACHINE > SOFTWARE > Altiris > eXpress. Right-click Notification Server, click New, click DWORD Value, type FlushAgentEvents and press Enter. Change the value to 1 to stop the Altiris Agents from reporting in. Change it back to 0 to have the Altiris Agents report in.
• With many files here, a lot of the inventory NSEs will be out of date, since newer ones have been stored here. In these instances it is recommended to flush the queues and schedule a Full Inventory to get systems back up to date. There have been instances where older inventory overwrites newer.

Server Logs

For transport problems, usually there is one type of message that indicates problems with Inventory reaching the server, and thus the Evtqueue.

NS Event Queue (EvtQueue) is full - returning BUSY

The A logs are reporting NS Event Queue (EvtQueue) is full - returning BUSY.

Cause

In the HKLM\Software\Altiris\express\Notification Server registry location are a number of keys:

MaxFileQEventCount - Default is 20000. Indicates that only 20K files are allowed into each queue before the queue is considered full.

MaxFileQSize - Default is 512000 (512K). Indicates the sum of the memory size of all of the NSEs in a queue.

These settings are global for all queues.

EvtQueueCurrent Size - The current disk space that the NSEs in the EvtQueue are currently using. There is a similar key for the EvtQFast and EvtQSlow queues.

EvtQueueCurrentCount - The current count of NSEs in the EvtQueue folder. There is a similar key for the EvtQFast and EvtQSlow queues.

EvtQueueFull- If either the EvtQueueCurrentSize or the EvtQueueCurrentCount exceed MaxFileQEventCount or the MaxFileQSize, the value of this setting is set to 1. The NS will begin reporting that the server is busy because the EvtQueue is full. There is a similar key for the EvtQFast and EvtQSlow queues.

In this case, the MaxFileQEventCount was set to 60000 and the MaxFileQSize was set at 512000. Even though only 11000 NSEs were in the EvtQueue, they exceeded the 512MB limitation set by the registry.

Solution

The MaxFileQSize registry setting value is limited only by the amount of available disk space on the Notification Server. Increasing the value of this setting to 1512000 (1.5 GB) can resolve the issue.

NSE capture options

Another way to see if NSEs are being sent is to enble a registry setting on the client computer. This setting is located in the registry. Follow this process to enable and view sent NSEs.

1. Go to Start > type Regedit > press Enter.
2. Browse under HKEY_LOCAL_MACHINE > SOFTWARE > Altiris > Altiris Agent > and select Transport.
3. Locate the value "Capture Events Folder".
4. Provide a path where outgoing NSEs can be copied, such as C:\files\NSEs.

5. Close the editor.

Nothing else needs to be done. Now when Inventory is run the NSE will be copied to that location. Since the naming convention does not tell you what the NSEs are, check the size. Inventory NSEs will be larger. Also note the creation time and correlate it for when an Inventory Policy completed.

Wireshark

Wireshark has a lot of capacity, and is thus can be intimidating in its complexity. For our purposes, Wireshark is very easy to use. All we need to look for is traffic between two IP Addresses, that of the server and the client. Things to watch for are:

• Packets being received and sent between the server and client
• Successful posts to postevent.asp.
• Any errors shown in communication between the two

Other Network monitoring programs can be used, but for this example I chose Wireshark because I have experience in it. I used version 1.6.5 in these instructions. To use Wireshark, please follow these steps:

1. Install and launch Wireshark on the Notification Server.
2. In the Capture pane, click on the hyperlink for the interface (network card) you want to monitor traffic on.
3. Sent Inventory (NOTE: you will want to type the capture around the time the inventory completes if possible since the amount of data being captured will be large.
4. Once complete, click the stop live capture icon, or go to the capture menu and choose Stop.
5. To filter the results, use the following filter logic:
   ip.addr == 10.0.0.1
6. Click Apply.
7. Now you can see all traffic to and from the Notification Server from that client.

In the Info column you should see the URL being used, and the Protocol will be HTTP (or HTTPS if SSL is being used). This will let you confirm if information is being sent from the client and reaching the server. If you can't find any references here, then we know the server is not seeing anything from the client.

Return to Part 2: Troubleshooting Inventory Solution 7.5 (also 7.1), Part 2

Continue on to Part 4: Troubleshooting Inventory Solution 7.5 (also 7.1), Part 4

Here is a doc which describes, how customers can configure own environment and add separate tasks to get latest information delivered more quickly to Parent Server from all managed Child Servers in Hierarchy to see how goes software installations on each client managed by each Child Server.

These reports on Parent Server will contain up-to-date data during each day (according to schedule, which will set customer):

Hierarchy software deployment to child clients from parent server and real-time software installation status monitoring via Parent reports

Scenario purpose:

Customers want to replicate and install software packages to all child server(s) managed clients from parent server via replication down of "Managed delivery" policy and see real-time progress of this deployment from all child clients on Parent server report

“Emergency Update” option is the best way how to quickly perform replication of “Managed Delivery” policy from Parent to all child Servers and force all Package Server(s) to download this new package(s):

Steps how to gather all event data of executed software installation(s) from all Child Server clients and send summarized data to Parent Server to get more real-time report data.

• On Parent Server and on each Child Server you need to manually create a "Scheduled Task"

(This task will summarizes all Software installation execution statuses on each Child Server and then hierarchy report will contain up to date software execution status)

• How to create such scheduled task to schedule this summarization execution on each child and on parent server as well:

→ Click "Start"→ "Administrative Tools"→ "Task Scheduler"
→ Mouse right click menu on "Task Scheduler"→ "Create New Task"
-- In "General" tab: Specify name and description on
-- In "Triggers" tab: Specify to run this task "Daily" and set to repeat it every %n% (for example "1 hour" or as often as you want to summarize execution event data on server)
-- In "Actions" tab: click "New"→ choose "Start a program"→ click "Browse"→ C:\Program Files\Altiris\Notification Server\Bin\ScheduleProcessor.exe
⇒ specify this {b9663013-def2-44d6-8cd5-dcff79297e71} GUID in "Add arguments" field and save changes.

Question: Why we need to create this custom scheduled task?

Answer: Because this item {b9663013-def2-44d6-8cd5-dcff79297e71} is included with other items in "NS.Daily" shared schedule, therefore we don't need another tasks execution on scalable environment to avoid unnecessary server load.

About custom scheduled task with item {b9663013-def2-44d6-8cd5-dcff79297e71}:

<item guid="b9663013-def2-44d6-8cd5-dcff79297e71"   classGuid="38594257-051E-4162-8513-65F269AE9918">

<scheduling>
<enabled>True</enabled>
<!-- Daily schedule -->
<sharedSchedule>{8E6C708E-18BC-4EF9-ACEA-2DE826C4F3B9}</sharedSchedule>
</scheduling>
<dataClass>
<name>Inv_Software_Delivery_Summary</name>
<guid>2842e137-2825-4c23-9e78-46cdde995447</guid>
</dataClass>
<storedProcedure>
<name>spSWM_PopulateSoftwareDeliverySummary</name>
</storedProcedure>
</item>

This stored procedure "spSWM_PopulateSoftwareDeliverySummary" which summarizes latest "Managed Delivery" policy software execution events from clients on each Server (Child and Parent)

As often this stored procedure is executed on each Child server then each Child server will be able to replicate latest execution status events to Parent Server, therefore customer(s) will be able to see up to date “MD” policy execution(s) information using these reports on Parent Server:

"Run Status Summary - by Management Server" report

"Run Status Summary - by Software" report

How to make software delivery event data replication from child servers to parent server

• Faster event data replication scenario: If customer has set a separate scheduled task “spSWM_PopulateSoftwareDeliverySummary” (described above) then he can set a separate schedule for "Software Delivery Summary Replication" replication rule and set to repeat this rule execution as much often as it is required on each Child Server.

Summary:

If you have created a separate scheduled task “spSWM_PopulateSoftwareDeliverySummary” on each Child Server to perform summarization of software installations from each Child server clients and set appropriate "Software Delivery Summary Replication" replication rule execution schedule on each Child Server, then you will have up-to-date data on Parent Server to see how is going software installations on clients computers from all your child servers, using these reports on Parent Server:

• "Run Status Summary - by Management Server" report
• "Run Status Summary - by Software" report

Feel free to ask any questions related to this acrticle.

Thanks,

IP.

Merging is based on resource key names and values. Unix, Linux and Mac (ULM) systems that have even a single matching resource key name and value combination will merge. Typical causes are:

• Common mac addresses from virtualization software or other predefined NICS
• Stale DNS caches
• Common ‘uniqueid’ resource key values, which are based solely on mac address values on Mac clients.

To find common resource keyname and keyvalue values:

1. On clients, run “aex-helper info resource”
2. Compare the keyname and keyvalues between machines. Any two computers with a matching key/value pair will merge. We can exclude the key or the value, per the following kb articles.

Resolving Shared Guids (Assigning a unique guid to each machine)

Do the following two steps, in order, to prevent and cleanup merged ULM resources:

1. Configure the NS or the agent on the client computers to not process specific resource keys and/or values by applying the resolutions in either or both of the following two KB articles:  
   • http://www.symantec.com/docs/HOWTO21641- How to exclude or ignore certain mac addresses as a resourcekey
   • http://www.symantec.com/docs/HOWTO60919- Managing resource keys for event generation on Unix, Linux & Macintosh clients
2. Assign new, unique resource guids to the affected client computers per the instructions in the following KB article:
   • http://www.symantec.com/docs/HOWTO84072 - How to Assign a New Resource Guid to a Unix, Linux or Mac Client Computer

The knowledge base capabilities that Workflow adds to Servicedesk are reasonably extensive.  In addition to a Bulletin Board Service, FAQ and WIKI capabilities, the functionality to add, approve, and rate articles that are added or moderated is helpful and useful.

 
Servicedesk users were required to add articles, etc., by using the smart task associated with an incident or change request that was visible on each of the respective process view pages.  In order to successfully use the options displayed on the Knowledge Base tab, you had to have membership in the Administrators group, or have specific portal permissions.
 However, by making the appropriate configuration changes, it is now possible to provide access for specific named groups, to be able to add any of the items available, essentially giving named groups, or users, the ability to quickly disseminate information to the system as a whole.  They are no longer limited to only performing the data entry via the process view smart task.  Bulletins, FAQ’s, etc., can now be added by those that have permissions.
The key catch is knowing what permissions to change.  To change the entries, you need to look at what needs to be done from a portal object perspective, rather than a group permissions view.  The Default Article Category Web part, on the Knowledge base page, has specific properties of its own, that control its use.  The permissions for that web part need to have the appropriate group added, and given the correct rights, to be able to not only view, but use the buttons effectively.
To set the correct permissions on the Default Article Category Web part, you should perform the following steps:
1.    As the Admin, login to the Portal and click on the Knowledge Base Tab.
2.    On the right side, you will see the  Default Article Category  web part.  In the upper right of that web part, click the lightning bolt, and select Edit Category, as shown below:
 
3.    Now , On the Edit category page, click the Permissions Tab, as shown below:
 

4.    Now you will need to add the permissions for the specific group that requires the new functionality.  Click Add Permission,   and change the permission type to Group, and then select the specific group you want.  Then, under the Allow column, .click Allow All, to extend all of the permissions to the new group.  Your screen should look like the below screen.
 

5.    Now click the Add button, then click the Save button.  
6.    You should now have the permissions available for members of the Support group.  You can now test.  
 
In our example above, this will allow any of the users in the Support group the ability to add the knowledge that they might obtain, that would be valuable to the group as a whole, in a quick and easily accessible way.

There's been a few post about retrieving host computername in a Workflow. Here's how I do it:

A little javascript to access the Altiris.SWRAgentUtils which - as I understand it - is used by the Softwareportal (http://<ns-server>/Altiris/SWD/SoftwarePortal.aspx)

I have a form with two textboxes named txt1 and txt2 ( to name a control 'Edit Component -> Functionality tab', check 'Specify Control ID' and type Control ID below)

Add the following code to the form: 'Edit form -> Behavior -tab -> Script - click the elipse(...):

function getPCinfo(){
var objAltiris = new ActiveXObject("Altiris.SWRAgentUtils");
var PCinfo = objAltiris.getMachineInfo();
var PCname = PCinfo.MachineName;
var PCguid = PCinfo.MachineGuid;
document.getElementById('txt1').value= PCname;
document.getElementById('txt2').value= PCguid;
 }

In the Body Custom Events click Add -> AttrubutesKeyValuePair
In the event-dropdown choose 'onload' and in the Eventhandler type:

getPCinfo()

You're now set to go - click OK and test away.
I'm no javascript-wiz so the script may not work in non-IE enviroments.

Cannot push Symantec Management Install remotely on Windows 7 computers

Issue:

Unable to push the Symantec Management Agent Install to Windows 7 computers  through the Symantec Management Console. When you look at the 'Status' of the install , it shows  'Failed to copy 'Symantec Management Agent install service'.

Cause:

The User Access Control  (UAC) Settings on the client computers need to be turned off. If it is turned on, the agent install service will not get copied from the server. UAC notifies when changes are going to be made on a computer that require administrator-level permission. Since the push is happening remotely from the server console, UAC denies the task of copying the service.

Solution:

You must be logged on the client computer as a local administrator to disable the UAC settings. Follow the steps below to disable the UAC settings for all users:

Log into the computer using admin account.

Click Start, click Run, type regedit, and then click Enter.

If prompted to enter your credentials, click on Yes to continue.

Navigate to the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

Look for the following keys and set their values to 0:

ConsentPromptBehaviorAdmin

EnableLUA

Reboot the computer.

Now try pushing the agent from the server console.

If the  computer is already showing up in the Rollout Agent to Computers window, remove it first.

Re-add it and hit ‘Install’. Provide the credentials having admin rights on the client computer.

Wait for a few minutes and hit the refresh button on the top right hand corner. You will see the status as success. Look at the Action field as well.

Trying to get the fundamentals around Symantec Workflow?  Some of our amazing Workflow gurus have put together demo videos that will go through all the basics.  Start from the first link and work your way through them all and you too will be a Workflow master!  (not as cool as a Jedi master, but certainly worth it)

Introductory Videos

• Basic Overview Video
• Overview of Project Types
• Overview of Component Types
• Overview of DataTypes

Training Video Sequence

- Basic Data and Rule Examples

• Add New Data
• Initialize Data
• Text Matches Rule
• Number Range Rule
• Equals Rule
• Date Range Rule

- Decision Components

• Decision Path Video
• Decision Tree Path Video
• Decision Table Video
• Decision Tree Video

- Collections

• For Each Element - Iterating Collections

- Complex Data Types

• Creating Custom Complex Data Types

- SQL Table Generator

• SQL Table Generator (Video 1) Read Records and Display in a Datagrid
• SQL Table Generator (Video 2) Insert Record
• SQL Table Generator (Video 3) Edit/Update Records

- Web Service Generator

• Web Service Generator Video

- Altiris Report Generator

• SharePoint & Report Generator Video

- XML Schema Generator

• Reading XML Data into a Workflow Video

- Workflow

• Auto Start Workflow From Email
• Basic Workflow "How To" Video
• Parallel Workflow - New Hire Request

- Process Development Walk-Throughs

• Change Request Step 1 - Version Management
• Change Request Step 2 - Request Submission
• Change Request Step 3 - Approval
• Change Request Step 4 - Approval To DB

Table of content:

• Introduction
• Unpacking
• Installing
• Console items
• Run Once
• Scheduling
• Custom destination
• Conclusion

Introduction:

If you look around Connect for Patch Trending you will find a number of downloads, articles or even blog post. These are the result of a customer driven process that allowed the tool set to grow organically to something sizable.

This document aims to be the only place you need to go through to get up and running with the tool.

Top

Unpacking:

The installation pack is available from the Site Builder download page, but here is a quick link (at version 15):

https://www-secure.symantec.com/connect/sites/default/files/Patch Trending Package.zip.

Unpack the package into a location of your choice:

Top

Installing:

Note! If your SMP is _not_ installed using the default drive and path you'll need to customise the installation directory - see below for the details.

Open an elevated command prompt and go to your package directory to run "install.bat".

The installation process will:

• Copy SiteBuilder-v14.exe to the destination folder
• Copy SiteBuilder-v14.exe to SiteBuilder.exe in the destination folder
• Copy site-layout.txt to the destination folder
• Copy web.config to the destination folder
• Import 5 items into the SMP database

The destination folder by default is: "C:\Program Files\Altiris\Notification Server\Web\PatchTrending\". This allow you to navigate to the generated site via the link http://localhost/altiris/ns/patchtrending/.

Top

Console items:

The SMP console will now have the following items at the root of the "Job and Task" folder:

• Run SiteBuilder (Patch Trending)
• RunOnce SiteBuilder (Install SQL code)
• TRENDING Compliance by computer
• TRENDING Compliance by update
• TRENDING Inactive computer

Top

Run once:

The SiteBuilder executable contains all the required stored procedure to trend compliance by update, compliance by computer and inactive computers. To add the procedures into the db (or rest them) the site builder must be invoked with the command line option "/install".

This is done by running the task "RunOnce SiteBuilder (Install SQL code)".

Top

Scheduling:

Next you need to schedule the 4 remaining tasks to run daily. The trending tasks (that run the SQL) are best run at the end of the day (so you collect and display data for the day on which the collection is done) and the Site Builder task must run once the trending task completed.

Here is an sample scheduling table:

Top

Custom destination:

If your Notification Server directory is not under the default drive and path you need to take a few additional steps from the above process to install the toolkit.

On the command line and before running install.bat you must set the installation directory in this manner:

set installdir="<desired destination folder>"

For example:

set installdir="C:\Program Files\Altiris\Patch Trending"

or

set installdir="D:\Altiris\Notification Server\Web\Patch Trending"

Once the items are imported in the SMP console, you need to modify the 2 tasks that run site builder with your custom path:

Top

Conclusion:

With the data collection and site builder scheduled to run you should be able to see some results after a couple of nightly execution (the first night should build up the site with empty graphs and the second night will bring in the data required to draw lines).

Here is the link you'll need to use to access the site builder landing page:

http://<your_smp_name>/altiris/ns/patchtrending

Note that if you have configured the IIS to listen to a different port the port number will have to follow the smp host name or fqdn, with a colon delimiter (i.e. http://<your_server>:8080 if you have changed the default port to 8080).

Top

References:

[1] {CWoc} Patch Trending SiteBuilder
[2] {CWoC} Patch Trending: Adding Patch Compliance Trending Capacity ...
[3] {CWoC} Patch Trending Stored Procedures
[4] {CWoC} Patch Trending: Adding a Compliance by Computer module
[5] {CWoC} Patch Trending: Inactive Computer Trending Report