Windows 7 and Rdeploy (My story…)

What did I do….

I installed my Windows 7 in a virtual environment …Just a next, next, finish setup.
I then then run sysprep (c:\windows\systems32\sysprep). I chose OOBE with the Generalize option.
I did not create a sysprep.XML to continue…(I was still downloading the WAIK to create an XML).

So after the sysprep was finished my PC was shutdown. I took an image using Ghost and one with Rdeploy.

It will take about 10 min (in my virtual setup).

When I boot the PC it will return an error like this.

When I start my WINPE again and I run bcdedit then my drive looks like this:

I now run these commands in a script in the WIN PE environment (same as Ghost and Rdeploy):

BCDEDIT /set {bootmgr} device partition:c:
BCDEDIT /set {default} device partition:d:
BCDEDIT /set {default} osdevice partition:d:

Running these command will fix the error you get. Making the image boot again.

Automating the completion of the Contact Information page in Symantec Installation Manager

Complete the following steps to create a config.xml file that contains the contact information and to populate the Contact Information page with this data when Symantec Installation Manager runs:

1. Use the following XML to create a config.xml file that contains your data:
   <?xml version="1.0"?>
   <simConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
          <downloadConfig>
                 <tradeComplianceConfig>
                       <!--The personal information required for trade compliance (required for tradeComplianceConfig)-->
                          <personalInformation>
                              <organization>company Name</organization>
                              <firstName>first name</firstName>
                              <lastName>last name</lastName>
                              <email>email address</email>
                              <address1>company address</address1>
                              <address2 />
                              <country>country</country>
                              <city>city</city>
                              <stateProvince>state or province</stateProvince>
                              <zipCode>zip code</zipCode>
                              <phone>phone number</phone>
                          </personalInformation>
                 </tradeComplianceConfig>
          </downloadConfig>
   </simConfig>
2. Copy the config.xml file to each Notification Server.
3. Launch Symantec Installation Manager with the following command line:

SymantecInstallationManager.exe /configfile <filepath> where <filepath> is the path to the config.xml file that you created.

When Symantec Installation Manager runs, it automatically populates the Contact Information page with the data you entered in the config.xml file.

NS6.0 Common problems for very large environments

 

Applies To

• Application Metering Solution 6.1
• Asset Control and Contract Management Solution 6.1, 6.2
• Inventory Solution for Windows 6.1
• Notification Server 6.0
• Patch Management Solution for Windows

Recovery Solution

• Default configuration of the RS database is configured to grow in 1MB increments.  Database can easily grow to 50+ GB.  All environments can safely change the growth rate to 10% of prior DB size.  Because the database file growth occurred in very tiny increments, the disk will be heavily fragmented.  Use traditional disk defragmentation tools to defrag the database (after temporarily stopping the SQL service). 
• New RS implementations should strongly consider increasing the allocated database file size to 30GB.  This minimizes the file fragmentation issue, and avoids a performance hit that occurs each time the database file size is automatically increased.  Rule of thumb for RS database size is 2-5% of the space used to store the backed-up files.  Smaller environments will be closer to the 5% end of the range.  Large environments will be closer to 2%.

Patch Management

• New PMimport.cab releases cause a large temporary spike of Inventory Rule retrieval and uploading of new scanning data. This load spike can overwhelm IIS to the point that the NS console is unavailable for 4–8 hours.

  Patch Management 6.2 supports the ability to move the Inventory Rule Web service to a separate application pool. This technique isolates the rest of the Notification Server from the load spike that was overwhelming standard agent and console communications. See article 25655 for implementation instructions.

• Patch Inventory Rule scanning is too frequent. Avoid using intervals less than the default of 4 hours in production environments. 

Application Metering

• Enabling monitoring of start and stop events for .exe files can overwhelm the server with event traffic. This is not recommended for any customer, but particularly painful for large environments. 
  The newest version of Application Metering includes some batch upload capabilities that may resolve this concern.
• Disable the "All Applications" Monitor Policy as it will enable all the clients to send summary data for every .EXE.

Inventory Solution

• Using the default of running all Inventory scanning on all computers at the same time each day or week will temporarily flood the NS queues until all NSEs have been processed. To alleviate, break-up inventory scanning into multiple collections which run on different days or utilize aexruncontrol.exe to randomize the scan times.
  For implementation details, see article 32175, "How to scale Inventory Solution in very large environments."

Asset Management

• Client facing Notification Servers with 10,000 plus nodes do not respond quickly (on a consistent basis) due to the inevitable spikes in agent communication and data uploading. The real time interaction for Asset Management functions involves lots of data entry. To avoid console performance delays, implement a secondary Notification Server and forward the inventory to the dedicated Reporting/AMS server.

Notification Server

• Collection update intervals are too frequent. The Notification Server and SQL will spend too much processing time rebuilding collections which could be better spent replying to agent requests, processing NSEs, and rendering the Notification Server console. 
  To avoid problems, stagger the delta and collection update schedules, and increase to 4+ hours.
• Agent check-in intervals are too frequent. Agent configuration request processing is usually the highest source of load on the Notification Server. Agent policies (Tasks) aren't frequently modified due to change control procedures (in very large environments). Checking in too frequently results in the agents retrieving no new configuration data. The Notification Server must still review all enabled policies that apply to the agent.
  To avoid problems, increase the Altiris Agent check-in interval to a more reasonable setting such as 4–6 hours.
• Report rendering hurts server performance. By default, the display row count is remembered for all future reports. Customers will frequently set the display row count to "All", which is fine for some smaller reports, but will cause 50,000 rows to returned for others.
  To avoid performance problems, update a SQL stored procedure (article 22542) This will reset the display row count before running each report.
• Resource Data History tab: In large environments (10,000 plus nodes), the query behind the History tab within the Resource Manager can cause severe CPU/Memory and SQL utilization spikes. 
  To avoid the issue, implement a reporting Notification Server (forward the inventory to it), and avoid viewing the Resource History data on the client facing Notification Server.
• Improving IIS and Notification Server response times by disabling debug mode: This is a common configuration that can (and should) be safely disabled on any Notification Server. High traffic environments with multiple Notification Server console users are the most heavily impacted. Follow the instructions as provided in article 33499.

DMC and DCM with SMP7 SP2 (or NS 7 SP2)

Please DO NOT apply the upgrade when using Dell Management Console or Dell Client Manager.
A new version of DMC 1.1 will be available around september that will work with SMP7 SP2 (or NS7 SP2).

New Releases

As Symantec is releasing more and more components I will try to summerize them each month.

New in July 2009:

1. SMP70.SP2 Hotfix1: performnace and bugfixes
2. Connector Solution 7.0: New in SMP7.0, NO more vendor conector solutions provided like HP Openview, SMS connector etc.
3. Workflow 7.0: New in NS7.0 and base for ServiceDesk 7.0 (target end august 2009)

Forecast (no commitments):

• Service Desk : end august 2009
• CMS SP1 : september 2009

Symantec Management Platform 7.0 SP2 Hotfix 1 Release Notes

After aplying the SP2 upgrade you should return to the SIM to apply the hotfix update.

This is described in article KB48033

Symantec™ Management Platform 7.0 SP2 Release Notes

The FULL release notes of SP2 are to be found in this following KB 46035.
Click Here to read all about the following upgrades:

• Core NS7
• Sofware Management framework (with Data Provider)
• Event Console
• Task Server
• Network Discovery
• Credential Manager

A BIG Performance improvement is noticed after applying this upgrade.

Upgrade / Install for Notification Server NS7 Sp2 via Symantec Installation Manager

There is no option to install SP2 for Notification Server via installing updates. It needs to be done through the "Install new products" option.
Example:- Start the the Symantec Installation Manager. This will update Symantec Installation Manager to update as well as the product listing.- Select install new products. SP2 will not display if you just select to install updates.- Choose to Filter on Platform- Install the Symantec Management Platform SP2 and Symantec Management Platform SP2 Hotfix 1- Review the selections and hit next to continue.- Follow the prompts to continue the installation.

What to know more on Workflow?

Check out this site as it a very good consolidated site for Workflow: http://www.workflowswat.com/

Is there a way to skip the install readiness checks during the install?

Yes.  Of course skipping the pre-req checks can result in undefined behavior of the product.  But there may be a case, for example, where the CPU speed does not meet the minimum specs even though you have multiple processors.

To disable the check for SIM prerequisites:
Add the key HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\AIM to the registry.
Create a DWord called IgnoreInstallPrerequisites and set the value to 1.
To enable the Next button if any of the install Readiness checks fail:
Add the key HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\AIM\InstallReadinessCheck\ to the registry. Create a DWord called EnableNextbutton and set the value to 1.

All known GUIDs from the Class table

https://kb.altiris.com/article.asp?article=24352&p=1

Nice article if you are troubleshooting GUID’s

Resolving the Certificate Revocation List (CRL) lookup performance issue

The symptoms of the Certificate Revocation List (CRL) lookup performance issue on the Symantec Management Platform computer are:

• Windows services on the Platform computer sometimes fail during startup.
• Some Symantec Management Console pages take a very long time to load.

---

Environment

This problem typically happens if the Symantec Management Platform computer is not connected to the internet, or is unable to resolve the Microsoft CRL server address. However, the problem may also arise if the Symantec Management Platform computer goes offline for an extended period. The computer will start exhibiting these performance issues after being offline for 15 days, as the CRL data is cached for 15 days.

---

Cause

This problem is caused by the Certificate Revocation List (CRL) lookup.  
If the Symantec Management Platform computer does not have internet access, the .NET runtime cannot access the Microsoft Certificate Revocation List servers to verify the Authenticode assembly. Although none of the applications that comprise the Symantec Management Platform make use of Authenticode assembly signing evidence, the standard Microsoft assemblies that are included with the .NET framework are all Authenticode signed. When the computer has no internet connection, .NET will try for up to 15 seconds to access the CRL before timing out as a failure.
This delay can lead to Windows services failing during startup, as some services take a long time to start and may time out. This delay also causes some Symantec Management Console pages to take a very long time to load.

---

Resolution

To resolve this problem, we recommend that you disable CRL lookups if the Symantec Management Platform computer is offline, or is likely to be offline for an extended period of time. You can re-enable CRL lookups later, if necessary.

Disabling CRL lookups

To disable CRL lookups on the Symantec Management Platform computer, you need to edit the machine.config file on the computer, as follows:

1. Open the machine.config file in a text editor.
   The machine.config file is located at %runtime install path%\Config\machine.config, where the runtime install path is usually C:\Windows\Microsoft.NET\Framework\v2.0.50727\.
2. Add the following XML element to the machine.config file:
   <configuration>
      <runtime>
   <generatePublisherEvidence enabled="false"/>
      </runtime>
   </configuration>
3. Save the machine.config file.

Re-enabling CRL lookups

If the Symantec Management Platform computer is later given internet access, you may need to re-enable CRL lookups. The Symantec Management Platform does not detect when access to the CRL server is restored, so will not make any changes to the machine.config file automatically. You only need to reverse the change to the machine.config file if applications or .NET security policies that require publisher evidence are installed on the computer. This is not common.
To re-enable CRL lookups manually, do the following:

1. Open the machine.config file in a text editor.
2. Delete the following XML element from the machine.config file:
   <generatePublisherEvidence enabled="false"/ >
   Ensure that you delete only this line from the machine.config file. Do not delete any other XML elements (such as the surrounding <configuration> and <runtime> elements), as they could be required for other customized options specified in the file.
3. Save the machine.config file.

Disabling CRL lookups for individual applications

In some circumstances you may not want to disable CRL lookups computer-wide, but need to disable them for individual applications. To disable CRL lookups for a particular application, open the appropriate application .config file (the naming convention is application name.config), and add the required XML element as specified for the machine.config file. If the necessary .config file does not exist for the application, you can create it.

The same applies to web.config files for web applications.

Note

When you install the Symantec Management Platform, the Install Readiness Check now includes a check for CRL access. If the computer does not have the necessary access, the check recommends that you disable CRL lookups for all .NET applications on the computer. You can do this automatically by accepting the "Fix" prompt displayed in the Symantec Installation Manager.

For more information, refer to the following KB article: About the Install Readiness Check for Certificate Revocation List access.

Best Practice references for Symantec Management Platform 7.0 (Article ID: 47816)

Planning and Documentation Symantec Management Platform 7.0 SP1 Release Notes  KB45229 Symantec Management Platform Support Matrix  KB46349 Symantec Management Platform Capacity Planning  KB45597 Planning & Design Considerations for Hierarchy & Site Management  KB47298     Installation and Migration Altiris 7 Planning & Implementation Guide  KB45803 Symantec Management Platform 7.0 Installation Guide  KB47819 Upgrading to Symantec Management Platform 7.0 on a different computer  KB45569     Backup and Recovery Backing up the Notification Server database  KB25600 Restoring Notification Server from a backup or upgrading it to new hardware  KB45606     Performance Tuning Creating a SQL maintenance plan to optimize database performance  KB40488 Understanding the /3GB and /USERVA switches, and Free System Page Table Entries  KB25079 How to create a Performance Monitor counter set for Altiris support  KB32258 Common Performance Monitor counter thresholds  KB45425     Troubleshooting What information should I collect when troubleshooting Symantec Installation Manager 7.0?  KB43175