From the deployment console, use the remote agent installer tool, change the agent settings the way you want them, by clicking the change settings button, Add a test computer but dont click the finish button, click on export, this will export clients.rci file which holds the settings, then rename that clients_pcname.inp file
to Aclient.inp. You can do two things with the Aclient.inp.
Create a deployment job to install the Aclient using these settings by running something like
Aclient.exe aclient.inp -Install -Silent
Or if you just want to change settings and not install aclient,, create a copy job in DS
Point the file to copy to the aclient.inp
use the destination just like
settings:aclient.inp
Thx Tim.
Steve Gibson made a GPO for this, you can find more info at : Steve's site
Thx Steve
Blog site to provide a quick way to find solutions on problems encountered during a day to day work. Some articles are just copies of KB or Forums, but they might come in handy.
25 April 2006
Helpdesk: These common words were ignored:" every word we search for"
Here is what I suggest you try, keeping in mind all the best practices concerning backups and testing and not suing me if something goes wnrgo:
Using SQL Enterprise Manager, expand the incident database (usually Altiris_Incidents), then click on Full-Text catalogs. There should be one: HD_workitem_comment. Right-click on that and choose " Rebuild catalog" .
Also, find the workitem table in Tables and right-click on that. Drill into the Full-Text Index menu and make sure Change Tracking and Update Index in Background are checked. That' s what keeps the full-text index up to date.
SQL 2005 has a new UI that is a little different but the same basic capabilities are there: look under the Storage folder to find the full-text catalog. The Full-Text Index menu for the workitem table has Track Changes Automatically available as a choice if tracking hasn' t been turned on.
It seems like SP3 doesn' t correctly turn that tracking on for SQL 2005 when you create a new database. I don' t know why it would turn it off on sql 2003 or 2000 if it was on previously. Are these new databases that you' re seeing the problem in?
Using SQL Enterprise Manager, expand the incident database (usually Altiris_Incidents), then click on Full-Text catalogs. There should be one: HD_workitem_comment. Right-click on that and choose " Rebuild catalog" .
Also, find the workitem table in Tables and right-click on that. Drill into the Full-Text Index menu and make sure Change Tracking and Update Index in Background are checked. That' s what keeps the full-text index up to date.
SQL 2005 has a new UI that is a little different but the same basic capabilities are there: look under the Storage folder to find the full-text catalog. The Full-Text Index menu for the workitem table has Track Changes Automatically available as a choice if tracking hasn' t been turned on.
It seems like SP3 doesn' t correctly turn that tracking on for SQL 2005 when you create a new database. I don' t know why it would turn it off on sql 2003 or 2000 if it was on previously. Are these new databases that you' re seeing the problem in?
19 April 2006
Deployment Solution 6.5 Hardware Independent Imaging
here you can find how to make an hardware independent image for to be used with Deployment Server 6.5 and Sysprep
http://kb.altiris.com/article.asp?article=21224&p=3
http://kb.altiris.com/article.asp?article=21224&p=3
18 April 2006
Using Software Delivery Solution to Install Internet Explorer ActiveX Compatibility Patch for Mshtml.dll (MS06-013)
Using Software Delivery Solution to Install Internet Explorer ActiveX Compatibility Patch for Mshtml.dll
Problem
The Altiris Console reacts differently to ActiveX Controls after installing the patches included in Microsoft's KB article 912945, "Internet Explorer ActiveX update," or KB912812, "MS06-013: Cumulative security update for Internet Explorer."
Environment
Microsoft Windows XP Service Pack 2
Microsoft Windows Server 2003 Service Pack 1 (SP1)
Notification Server 6.0 SP3 (6.0.6074), older versions will most likely react to the ActiveX update in the same way.
Cause
Microsoft made minor changes to the way that Internet Explorer handles some Web pages that use ActiveX controls. See Microsoft Security Advisory (912945) published Feb 28,1006:
http://www.microsoft.com/technet/security/advisory/912945.mspx
and press release:
http://www.microsoft.com/presspass/press/2003/oct03/10-06EOLASpr.mspx
Resolution
Install Microsoft Compatibility Patch KB917425 Internet Explorer ActiveX compatibility patch for Msdhtml.dll. See:
http://support.microsoft.com/kb/917425/en-us
Note: You only need to install this patch if you have previously installed the KB912945 or KB912812 patches. This patch should give you an error if you have not previously installed one of the other two patches. The preferred method of installing these patches is to follow the instructions on the Microsoft Web site, especially for your Microsoft 2003 Server computers.
However, to help facilitate the installation of these patches, you may download the attached Compatibility Patch (KB917425).xml file that contains two Software Delivery Tasks that utilize the same Software Delivery Package and import it into your Notification Server console.
Download both the Windows 2003 and Windows XP patch files from the URL above. The two filenames are:
WindowsServer2003-KB917425-x86-ENU.exe
WindowsXP-KB917425-x86-ENU.exe
Place these two files in a folder that is local to your NS server.
Import the Compatibility Patch (KB917425).xml file by right-clicking on a suitable location in your Console and selecting import. A good location might be the Task tab > Software Management > Software Delivery > Windows > Software Delivery Tasks.
Modify the Package Location: field in the "ActiveX Compatibility Patch (KB917425)" package to point to the folder you created in step 1.
Apply the change and be sure to "Update Distribution Points".
The tasks are set to apply to the "All 32-bit Windows 2003 Servers"/"All 32-bit Windows XP Computers" collections. If the KB912945 or KB912812 patches are not installed on the computers in these collections, you will need to modify the Applies to collections: field appropriately.
Enable the tasks.
Problem
The Altiris Console reacts differently to ActiveX Controls after installing the patches included in Microsoft's KB article 912945, "Internet Explorer ActiveX update," or KB912812, "MS06-013: Cumulative security update for Internet Explorer."
Environment
Microsoft Windows XP Service Pack 2
Microsoft Windows Server 2003 Service Pack 1 (SP1)
Notification Server 6.0 SP3 (6.0.6074), older versions will most likely react to the ActiveX update in the same way.
Cause
Microsoft made minor changes to the way that Internet Explorer handles some Web pages that use ActiveX controls. See Microsoft Security Advisory (912945) published Feb 28,1006:
http://www.microsoft.com/technet/security/advisory/912945.mspx
and press release:
http://www.microsoft.com/presspass/press/2003/oct03/10-06EOLASpr.mspx
Resolution
Install Microsoft Compatibility Patch KB917425 Internet Explorer ActiveX compatibility patch for Msdhtml.dll. See:
http://support.microsoft.com/kb/917425/en-us
Note: You only need to install this patch if you have previously installed the KB912945 or KB912812 patches. This patch should give you an error if you have not previously installed one of the other two patches. The preferred method of installing these patches is to follow the instructions on the Microsoft Web site, especially for your Microsoft 2003 Server computers.
However, to help facilitate the installation of these patches, you may download the attached Compatibility Patch (KB917425).xml file that contains two Software Delivery Tasks that utilize the same Software Delivery Package and import it into your Notification Server console.
Download both the Windows 2003 and Windows XP patch files from the URL above. The two filenames are:
WindowsServer2003-KB917425-x86-ENU.exe
WindowsXP-KB917425-x86-ENU.exe
Place these two files in a folder that is local to your NS server.
Import the Compatibility Patch (KB917425).xml file by right-clicking on a suitable location in your Console and selecting import. A good location might be the Task tab > Software Management > Software Delivery > Windows > Software Delivery Tasks.
Modify the Package Location: field in the "ActiveX Compatibility Patch (KB917425)" package to point to the folder you created in step 1.
Apply the change and be sure to "Update Distribution Points".
The tasks are set to apply to the "All 32-bit Windows 2003 Servers"/"All 32-bit Windows XP Computers" collections. If the KB912945 or KB912812 patches are not installed on the computers in these collections, you will need to modify the Applies to collections: field appropriately.
Enable the tasks.
Items to help improve Console and Server performance in Notification Server
QuestionWhat can be done to improve the speed of the Notification Server and Altiris Console? What items can increase efficiencies?
Answer
Disabling Alert Manager Synchronization
How to Disable Alert Manager and Notification Server synchronization: below are the registry changes needed to disable the synchronization functionality of AlertManager/Helpdesk. This has proved to produce performance improvements on busy notification servers where AlertManager/Helpdesk asset and contact synchronization from the Notification Server is not required.
Using regedit, add the following two REG_SZ entries :
HKLM\Software\Altiris\eXpress\Helpdesk Package\DisableAutoUpdateProcessing = true
HKLM\Software\Altiris\eXpress\Helpdesk Package\DisableSyncIncidentProcessing = true
Stop the Altiris Service (AeXSvc.exe) and the Altiris Client Message Dispatcher service.
Go to Start > Run, and type "iisreset" and click OK. This will recycle IIS, including the worker process.
Start the Altiris Service (AeXSvc.exe) and the Altiris Client Message Dispatcher service.
Increasing SQL Performance by defragging the SQL indices
Several defrags can increase SQL performance.
1. SQL script to defrag all database indices for the Altiris database:
declare @index_name nvarchar(255)
declare @table_name nvarchar(255)
declare index_cursor cursor for
select
si.name as index_name,
object_name(si.id) as table_name
from sysindexes si
left outer join sysobjects so on so.name=si.name
where objectproperty(si.id, N'IsUserTable') = 1
and objectproperty(si.id, N'IsUserTable') = 1
and si.name <> object_name(si.id)
and si.impid <> -1
open index_cursor
fetch next from index_cursor into @index_name, @table_name
while @@FETCH_STATUS = 0
begin
print 'Attempting defrag of index [' + @index_name + '] on table [' + @table_name + ']'
dbcc INDEXDEFRAG( 0, @table_name, @index_name )
fetch next from index_cursor into @index_name, @table_name
end
close index_cursor
deallocate index_cursor
2. The above script defrags all the indices used in the Altiris database. Run this against the Altiris database using SQL Query Analyser or other SQL scripting tool.
3. Defrag SQL data and log volumes. Post upgrade the log files of the Altiris database can be heavily fragmented. Use Enterprise Manager or similar SQL management tool to defrag these volumes to greatly improve SQL performance Post-upgrade.
SQL Configuration Optimization
The following items can increase SQL performance, thus increasing the speed of the Notification Server and the Altiris Console.
An I/O is generally a separate hard drive. This is not true when using ATA/IDE drives and the two drives are mastered and slaved. Consequently, the hard drives would need to be on separate IDE/ATA ribbon cables. For SCSI, two separate drives can be on the same SCSI cable.
In SQL enterprise manager open the database properties.
In the Data Files and Transaction Log tabs, note the current location of the .MDF and .NDF (if used) data file(s) and the .LDF transaction log file(s).
Close the properties and right-click on the database > All Tasks > Detach Database.
Once the database is detached, manually move the .MDF, .NDF (if used), and .LDF files.
One of the suggestions from Altiris development is to place the .LDF file(s) on a separate physical disk from the data file(s). This should allow transactions and data reads and writes to operate independently and concurrently.
After moving the .MDF, .NDF (if used), and .LDF files on the various drive locations, reattach to the database.
Open SQL enterprise manager, right-click on the Databases folder > All Tasks > Attach Database.
Use the ellipsis button ( … ) to browse to the current location of the .MDF file. This will populate a list of all the data files and their physical locations. The .MDF will be set based on the current location based on browsing with the ellipsis button. However, all the other data files will retain their paths as it knew them before the database was detached.
Each path location will need to be corrected for the new location of that file until the red X turns into a green checkmark.
Once all the file path locations have been set correctly, make sure that the database is the correct database name.
Click Verify and then, if that does not bring any errors, hit OK.
The database will not be using the new locations for each of the files. This should be verified by the properties of the database on the Data Files and Transaction Log tabs.
Another suggestion that comes from SQL is to move the tempdb to a FAST I/O physical disk drive. This makes a lot of sense given how heavy Altiris uses the tempdb (anytime a temporary table is created). If the server has three physical disks, the operating system should be on one, most of the database files on the other, and the third, with the fastest I/O, should have the transaction logs and tempdb data files.
Moving the tempdb data files is done a little differently than moving data files of other database because the tempdb cannot be detached. Microsoft provided a different way to do this for the tempdb database only.
In Query Analyzer run this command (substitute the correct drive and folders, placing these files on a fast I/O drive)
ALTER DATABASE tempdb modify file (name=tempdev, FILENAME= ‘e:\SQLDATA\tempdb.mdf’)
ALTER DATABASE tempdb modify file (name=templog, FILENAME= ‘e:\SQLDATA\tempdb.ldf’)
Stop and restart SQL Server service
Verify that the new tempdb.mdf and tempdb.ldf files have been created. Then go ahead and delete the older original copy.
If there are more than three physical disks available it is possible to split a little further. Spanning the tempdb data files across multiple physical disks increases performance further.
Microsoft Recommended SQL Optimizations
The following are optimizations recommended by Microsoft for increased performance of SQL in general.
Optimizing Transaction Log Performance. General recommendations for creating transaction log files include:
Create the transaction log on a physically separate disk or RAID (redundant array of independent disks) device. The transaction log file is written serially. Therefore, using a separate, dedicated disk allows the disk heads to stay in place for the next write operation.
Set the original size of the transaction log file to a reasonable size to prevent the file from automatically expanding as more transaction log space is needed. As the transaction log expands, a new virtual log file is created. Write operations to the transaction log wait while the transaction log is expanded. If the transaction log expands too frequently, performance can be affected.
Set the file growth increment percentage to a reasonable size to prevent the file from growing by too small a value. If the file growth is too small compared to the number of log records being written to the transaction log, then the transaction log may need to expand constantly, affecting performance.
Manually shrink the transaction log files rather than allowing Microsoft SQL Server 2000 to shrink the files automatically. Shrinking the transaction log can affect performance on a busy system due to the movement and locking of data pages.
Optimizing tempdb Performance - General recommendations for the physical placement and database options set for the tempdb database include:
Allow the tempdb database to automatically expand as needed. This ensures that queries that generate larger than expected intermediate result sets stored in the tempdb database are not terminated before execution is complete.
Set the original size of the tempdb database files to a reasonable size to avoid the files from automatically expanding as more space is needed. If the tempdb database expands too frequently, performance can be affected.
Set the file growth increment percentage to a reasonable size to avoid the tempdb database files from growing by too small a value. If the file growth is too small compared to the amount of data being written to the tempdb database, then tempdb may need to expand constantly, thereby affecting performance.
Place the tempdb database on a fast I/O subsystem to ensure good performance. Stripe the tempdb database across multiple disks for better performance. Use file groups to place the tempdb database on disks different from those used by user databases
Answer
Disabling Alert Manager Synchronization
How to Disable Alert Manager and Notification Server synchronization: below are the registry changes needed to disable the synchronization functionality of AlertManager/Helpdesk. This has proved to produce performance improvements on busy notification servers where AlertManager/Helpdesk asset and contact synchronization from the Notification Server is not required.
Using regedit, add the following two REG_SZ entries :
HKLM\Software\Altiris\eXpress\Helpdesk Package\DisableAutoUpdateProcessing = true
HKLM\Software\Altiris\eXpress\Helpdesk Package\DisableSyncIncidentProcessing = true
Stop the Altiris Service (AeXSvc.exe) and the Altiris Client Message Dispatcher service.
Go to Start > Run, and type "iisreset" and click OK. This will recycle IIS, including the worker process.
Start the Altiris Service (AeXSvc.exe) and the Altiris Client Message Dispatcher service.
Increasing SQL Performance by defragging the SQL indices
Several defrags can increase SQL performance.
1. SQL script to defrag all database indices for the Altiris database:
declare @index_name nvarchar(255)
declare @table_name nvarchar(255)
declare index_cursor cursor for
select
si.name as index_name,
object_name(si.id) as table_name
from sysindexes si
left outer join sysobjects so on so.name=si.name
where objectproperty(si.id, N'IsUserTable') = 1
and objectproperty(si.id, N'IsUserTable') = 1
and si.name <> object_name(si.id)
and si.impid <> -1
open index_cursor
fetch next from index_cursor into @index_name, @table_name
while @@FETCH_STATUS = 0
begin
print 'Attempting defrag of index [' + @index_name + '] on table [' + @table_name + ']'
dbcc INDEXDEFRAG( 0, @table_name, @index_name )
fetch next from index_cursor into @index_name, @table_name
end
close index_cursor
deallocate index_cursor
2. The above script defrags all the indices used in the Altiris database. Run this against the Altiris database using SQL Query Analyser or other SQL scripting tool.
3. Defrag SQL data and log volumes. Post upgrade the log files of the Altiris database can be heavily fragmented. Use Enterprise Manager or similar SQL management tool to defrag these volumes to greatly improve SQL performance Post-upgrade.
SQL Configuration Optimization
The following items can increase SQL performance, thus increasing the speed of the Notification Server and the Altiris Console.
An I/O is generally a separate hard drive. This is not true when using ATA/IDE drives and the two drives are mastered and slaved. Consequently, the hard drives would need to be on separate IDE/ATA ribbon cables. For SCSI, two separate drives can be on the same SCSI cable.
In SQL enterprise manager open the database properties.
In the Data Files and Transaction Log tabs, note the current location of the .MDF and .NDF (if used) data file(s) and the .LDF transaction log file(s).
Close the properties and right-click on the database > All Tasks > Detach Database.
Once the database is detached, manually move the .MDF, .NDF (if used), and .LDF files.
One of the suggestions from Altiris development is to place the .LDF file(s) on a separate physical disk from the data file(s). This should allow transactions and data reads and writes to operate independently and concurrently.
After moving the .MDF, .NDF (if used), and .LDF files on the various drive locations, reattach to the database.
Open SQL enterprise manager, right-click on the Databases folder > All Tasks > Attach Database.
Use the ellipsis button ( … ) to browse to the current location of the .MDF file. This will populate a list of all the data files and their physical locations. The .MDF will be set based on the current location based on browsing with the ellipsis button. However, all the other data files will retain their paths as it knew them before the database was detached.
Each path location will need to be corrected for the new location of that file until the red X turns into a green checkmark.
Once all the file path locations have been set correctly, make sure that the database is the correct database name.
Click Verify and then, if that does not bring any errors, hit OK.
The database will not be using the new locations for each of the files. This should be verified by the properties of the database on the Data Files and Transaction Log tabs.
Another suggestion that comes from SQL is to move the tempdb to a FAST I/O physical disk drive. This makes a lot of sense given how heavy Altiris uses the tempdb (anytime a temporary table is created). If the server has three physical disks, the operating system should be on one, most of the database files on the other, and the third, with the fastest I/O, should have the transaction logs and tempdb data files.
Moving the tempdb data files is done a little differently than moving data files of other database because the tempdb cannot be detached. Microsoft provided a different way to do this for the tempdb database only.
In Query Analyzer run this command (substitute the correct drive and folders, placing these files on a fast I/O drive)
ALTER DATABASE tempdb modify file (name=tempdev, FILENAME= ‘e:\SQLDATA\tempdb.mdf’)
ALTER DATABASE tempdb modify file (name=templog, FILENAME= ‘e:\SQLDATA\tempdb.ldf’)
Stop and restart SQL Server service
Verify that the new tempdb.mdf and tempdb.ldf files have been created. Then go ahead and delete the older original copy.
If there are more than three physical disks available it is possible to split a little further. Spanning the tempdb data files across multiple physical disks increases performance further.
Microsoft Recommended SQL Optimizations
The following are optimizations recommended by Microsoft for increased performance of SQL in general.
Optimizing Transaction Log Performance. General recommendations for creating transaction log files include:
Create the transaction log on a physically separate disk or RAID (redundant array of independent disks) device. The transaction log file is written serially. Therefore, using a separate, dedicated disk allows the disk heads to stay in place for the next write operation.
Set the original size of the transaction log file to a reasonable size to prevent the file from automatically expanding as more transaction log space is needed. As the transaction log expands, a new virtual log file is created. Write operations to the transaction log wait while the transaction log is expanded. If the transaction log expands too frequently, performance can be affected.
Set the file growth increment percentage to a reasonable size to prevent the file from growing by too small a value. If the file growth is too small compared to the number of log records being written to the transaction log, then the transaction log may need to expand constantly, affecting performance.
Manually shrink the transaction log files rather than allowing Microsoft SQL Server 2000 to shrink the files automatically. Shrinking the transaction log can affect performance on a busy system due to the movement and locking of data pages.
Optimizing tempdb Performance - General recommendations for the physical placement and database options set for the tempdb database include:
Allow the tempdb database to automatically expand as needed. This ensures that queries that generate larger than expected intermediate result sets stored in the tempdb database are not terminated before execution is complete.
Set the original size of the tempdb database files to a reasonable size to avoid the files from automatically expanding as more space is needed. If the tempdb database expands too frequently, performance can be affected.
Set the file growth increment percentage to a reasonable size to avoid the tempdb database files from growing by too small a value. If the file growth is too small compared to the amount of data being written to the tempdb database, then tempdb may need to expand constantly, thereby affecting performance.
Place the tempdb database on a fast I/O subsystem to ensure good performance. Stripe the tempdb database across multiple disks for better performance. Use file groups to place the tempdb database on disks different from those used by user databases
Microsoft .NET Frequently Asked Questions (FAQ)
Question
This article (taken from the "Microsoft .NET FAQs" help topic in Wise for Windows Installer and the Windows Installer Editor) answers questions about Microsoft .NET and defines important concepts you should understand before you use Wise for Windows Installer or the Windows Intsaller Editor to build .NET installations.
Answer
What does the common language runtime do?
The common language runtime manages the execution of code and provides services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support. See Common Language Runtime in the MSDN Library.
What's the difference between managed and unmanaged code?
Code developed with a language compiler that targets the common language runtime is called managed code. All code based on Microsoft intermediate language (MSIL) executes as managed code. Managed code is self-describing; it contains metadata that describes every element managed by the common language runtime. The runtime uses the metadata to provide services.
Code that runs outside the runtime and does not contain metadata is called unmanaged code. Examples of unmanaged code are COM components, ActiveX interfaces, and Win32 API functions. Unmanaged code executes in the common language runtime environment with minimal services.
I don't want to rewrite all my applications as managed code. Can I add managed code to an existing application?
Few developers will be able to rewrite existing applications completely as managed (.NET) code. Instead, you can combine managed and unmanaged components in one installation. Code that contains a mix of managed and unmanaged elements is called interoperable code.
The common language runtime supports COM interoperability (interop). For backward compatibility, COM interop provides access to existing COM components without requiring you to modify the original components. COM interop also enables your COM clients to access managed code as easily as they access other COM objects. This is accomplished by adding information to the system registry so .NET components are called as though they were COM components. At runtime, the common language runtime marshals data between COM objects and managed objects as needed.
See Interoperating with Unmanaged Code in the MSDN Library.
What is an assembly?
An assembly is the primary building block of a .NET application. An assembly contains its own naming, binding, versioning, deployment, and configuration information. It consists of two elements: a manifest, which is the metadata that describes information about the assembly and any resources it depends on; and a set of instructions in the form of Microsoft Intermediate Language (MSIL) code that is executed when the assembly is referenced.
You can group assembly elements into a single file assembly, which incorporates the manifest into a portable executable (PE) file, which can be an .EXE or .DLL, with the source code. You also can create a multifile assembly consisting of modules of compiled code, resources, or other files required by the application. In a multifile assembly, the manifest can be a standalone file or it can be incorporated into one of the PE files in the assembly.
When you add a .NET assembly to an installation, Wise for Windows Installer creates entries in the MsiAssembly and MsiAssemblyName tables.
See Assemblies in the Windows Installer SDK Help.
How does .NET reduce file sharing conflicts?
An important benefit of .NET installations is the reduction of file sharing conflicts. With the common language runtime, the assembly is described by a manifest; the registry is no longer relied upon for storing and accessing the COM activation data. This allows components to be fully isolated from each other.
Assembly sharing is accomplished in a number of ways:
To install .NET assemblies that are intended to be shared by many applications on the computer, make sure they are strongly named and install them into the Global Assembly Cache, which is a machine-wide code cache. Do not install assemblies into the Global Assembly Cache unless they specifically need to be shared. The Global Assembly Cache is available only if the .NET Framework is installed on the destination computer.
To safely share COM or Win32 assemblies among multiple applications and to minimize .DLL conflicts, use side-by-side assembly sharing. Instead of having a single version of an assembly that assumes backward compatibility with all applications, side-by-side assembly sharing enables multiple versions of a COM or Win32 assembly to run simultaneously on the system. Side-by-side assembly sharing is available only on Windows XP or later. See Side-by-Side Assemblies in the Windows Installer SDK Help.
To reserve a Win32 assembly for the exclusive use of one application, install it in a folder private to the application, typically the application directory. This is called a private assembly. The dependency of the application on the private assembly is specified in an application manifest file. On operating systems earlier than Windows XP, a copy of the private assembly and a .local file is installed into a private folder for the exclusive use of the application. A version of the assembly is also globally registered on the system and made available for any application that binds to it. The global version of the assembly can be the version installed with the application or an earlier version.
I thought .NET meant I could use XCOPY to install applications without registration. Why do I need to build a Windows Installer installation?
For a .NET application that uses only managed code and private assemblies, the installation process can be as simple as copying files to the destination computer. Most developers, however, will still need to create a compressed, single-file installation that is easy to deploy and that provides a friendly interface to the end user.
.NET applications that use shared assemblies, or that have a mix of managed and unmanaged code, cannot be installed via XCOPY. You should use the Windows Installer service for installations that do any of the following:
Install COM files
Install assemblies to the Global Assembly Cache
Require user information during the installation
Require security
Create a shortcut
Require elevated privileges to install on a locked-down computer
By creating a Windows Installer installation for your .NET applications, you can take advantage of the services Windows Installer provides: installation, repair, and removal of assemblies; roll back; install-on-demand; patching; and advertisement.
How does Wise for Windows Installer support .NET installations?
Wise for Windows Installer lets you install .NET assemblies into the Global Assembly Cache, or as side-by-side or private assemblies. It also lets you create mixed installations by registering .NET assemblies with COM.
If the .NET Framework is installed on your computer, Wise for Windows Installer can automate the process as follows:
Find all files in multifile assemblies and add them to the installation.
Scan for assembly dependencies and add them to the installation.
Determine attributes for registering the assembly files and add them to the MsiAssemblyName table.
Add registry keys for COM interop.
This article (taken from the "Microsoft .NET FAQs" help topic in Wise for Windows Installer and the Windows Installer Editor) answers questions about Microsoft .NET and defines important concepts you should understand before you use Wise for Windows Installer or the Windows Intsaller Editor to build .NET installations.
Answer
What does the common language runtime do?
The common language runtime manages the execution of code and provides services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support. See Common Language Runtime in the MSDN Library.
What's the difference between managed and unmanaged code?
Code developed with a language compiler that targets the common language runtime is called managed code. All code based on Microsoft intermediate language (MSIL) executes as managed code. Managed code is self-describing; it contains metadata that describes every element managed by the common language runtime. The runtime uses the metadata to provide services.
Code that runs outside the runtime and does not contain metadata is called unmanaged code. Examples of unmanaged code are COM components, ActiveX interfaces, and Win32 API functions. Unmanaged code executes in the common language runtime environment with minimal services.
I don't want to rewrite all my applications as managed code. Can I add managed code to an existing application?
Few developers will be able to rewrite existing applications completely as managed (.NET) code. Instead, you can combine managed and unmanaged components in one installation. Code that contains a mix of managed and unmanaged elements is called interoperable code.
The common language runtime supports COM interoperability (interop). For backward compatibility, COM interop provides access to existing COM components without requiring you to modify the original components. COM interop also enables your COM clients to access managed code as easily as they access other COM objects. This is accomplished by adding information to the system registry so .NET components are called as though they were COM components. At runtime, the common language runtime marshals data between COM objects and managed objects as needed.
See Interoperating with Unmanaged Code in the MSDN Library.
What is an assembly?
An assembly is the primary building block of a .NET application. An assembly contains its own naming, binding, versioning, deployment, and configuration information. It consists of two elements: a manifest, which is the metadata that describes information about the assembly and any resources it depends on; and a set of instructions in the form of Microsoft Intermediate Language (MSIL) code that is executed when the assembly is referenced.
You can group assembly elements into a single file assembly, which incorporates the manifest into a portable executable (PE) file, which can be an .EXE or .DLL, with the source code. You also can create a multifile assembly consisting of modules of compiled code, resources, or other files required by the application. In a multifile assembly, the manifest can be a standalone file or it can be incorporated into one of the PE files in the assembly.
When you add a .NET assembly to an installation, Wise for Windows Installer creates entries in the MsiAssembly and MsiAssemblyName tables.
See Assemblies in the Windows Installer SDK Help.
How does .NET reduce file sharing conflicts?
An important benefit of .NET installations is the reduction of file sharing conflicts. With the common language runtime, the assembly is described by a manifest; the registry is no longer relied upon for storing and accessing the COM activation data. This allows components to be fully isolated from each other.
Assembly sharing is accomplished in a number of ways:
To install .NET assemblies that are intended to be shared by many applications on the computer, make sure they are strongly named and install them into the Global Assembly Cache, which is a machine-wide code cache. Do not install assemblies into the Global Assembly Cache unless they specifically need to be shared. The Global Assembly Cache is available only if the .NET Framework is installed on the destination computer.
To safely share COM or Win32 assemblies among multiple applications and to minimize .DLL conflicts, use side-by-side assembly sharing. Instead of having a single version of an assembly that assumes backward compatibility with all applications, side-by-side assembly sharing enables multiple versions of a COM or Win32 assembly to run simultaneously on the system. Side-by-side assembly sharing is available only on Windows XP or later. See Side-by-Side Assemblies in the Windows Installer SDK Help.
To reserve a Win32 assembly for the exclusive use of one application, install it in a folder private to the application, typically the application directory. This is called a private assembly. The dependency of the application on the private assembly is specified in an application manifest file. On operating systems earlier than Windows XP, a copy of the private assembly and a .local file is installed into a private folder for the exclusive use of the application. A version of the assembly is also globally registered on the system and made available for any application that binds to it. The global version of the assembly can be the version installed with the application or an earlier version.
I thought .NET meant I could use XCOPY to install applications without registration. Why do I need to build a Windows Installer installation?
For a .NET application that uses only managed code and private assemblies, the installation process can be as simple as copying files to the destination computer. Most developers, however, will still need to create a compressed, single-file installation that is easy to deploy and that provides a friendly interface to the end user.
.NET applications that use shared assemblies, or that have a mix of managed and unmanaged code, cannot be installed via XCOPY. You should use the Windows Installer service for installations that do any of the following:
Install COM files
Install assemblies to the Global Assembly Cache
Require user information during the installation
Require security
Create a shortcut
Require elevated privileges to install on a locked-down computer
By creating a Windows Installer installation for your .NET applications, you can take advantage of the services Windows Installer provides: installation, repair, and removal of assemblies; roll back; install-on-demand; patching; and advertisement.
How does Wise for Windows Installer support .NET installations?
Wise for Windows Installer lets you install .NET assemblies into the Global Assembly Cache, or as side-by-side or private assemblies. It also lets you create mixed installations by registering .NET assemblies with COM.
If the .NET Framework is installed on your computer, Wise for Windows Installer can automate the process as follows:
Find all files in multifile assemblies and add them to the installation.
Scan for assembly dependencies and add them to the installation.
Determine attributes for registering the assembly files and add them to the MsiAssemblyName table.
Add registry keys for COM interop.
13 April 2006
12 April 2006
Package server Security, Installer, and Collection Definition Hotfix
Problem
Section 1—Summary
This update, when installed on Notification Server SP3, replaces the existing Package Server Agent package. Package Servers in your environment need to be upgraded to this version for any update changes to apply. This update contains the following:
· Install, upgrade, and uninstall of Package Server Agent through Wise Installer. This was previously performed by Installshield.
· Registry key added to control whether or not the Package Server Agent can manage/change the security on its package directories.
· All Windows Computer requiring Altiris Package Server Agent Upgrade collection updated to only include Package Servers with Altiris Agent build 6.0.2338 (SP3), or greater.
Section 2—Installation
Name: Notification Server 6.0 SP3 Update 17613
Prerequisite software:
· NS build 6.0 SP3 Version 6.0.6074.
· Altiris Agent SP3 Version 6.0.2338 installed on Package Server.
IMPORTANT: The updated Package Server is not compatible with Altiris Agent versions earlier than 6.0.2338.
2.1—Install the Update
1. Download ftp://ftp2.altiris.com/Download/KB17613/Altiris_NS_6_0_SP3_KB17613.exe
to your Notification Server.
2. Run Altiris_NS_6_0_SP3_KB17613.exe.
2.2—Uninstall the Update
If, for any reason, you need to uninstall the update, the Notification Server will restore the original SP3 version of the Package Server Agent package. You can remove this via the ADD/REMOVE Programs option in the Control Panel on the Notification Server.
IMPORTANT: All updated Package Server Agents rolled out must be uninstalled before uninstalling the update on the Notification Server.
2.3—Upgrading Package Servers
The All Windows Computer Requiring Altiris Package Server Agent Upgrade collection that applies, by default, to the Windows Package Server Agent upgrade task, will not contain Package Servers with an Altiris Agent version lower than 6.0.2338 (SP3). Once the Altiris Agent has been upgraded on the Package Server, they will appear in this collection.
When the Windows Package Server Agent upgrade task is run, the upgrade will take approximately 15–20 seconds. Do not be concerned if the Altiris Agent does not start back up immediately after the upgrade task has run; this pause is expected.
Note: If the Package Server Agent is accidentally upgraded before the Altiris Agent, (which may happen if you are using a collection other than the All Windows Computer Requiring Altiris Package Server Agent Upgrade collection) the Altiris Agent and Package Server will not function or run Software Delivery tasks until the Altiris Agent has been upgraded to the required version. To do this, go to the Altiris Agent Installation page on the Notification Server and push out the Altiris Agent to the computer. This will carry out an upgrade of the installed Altiris Agent, and both the Altiris Agent and Package Server will then function normally.
Section 3—New Features and Enhancements in this Update
3.1—Package Server using Wise Installer
The install, upgrade and uninstall of the Package Server Agent is now done by Wise Installer; it was previously done by Installshield. There is a known issue with Installshield Version 10.5 that causes installations to fail on some systems with terminal services enabled with the following error message:
An Error (-5006 : 0x80004005) has occurred while running the setup. Please make sure you have finished any previous setups and closed other applications. If the error still occurs, please contact your vendor: Altiris.
For information, see http://community.installshield.com/showthread.php?threadid=109023
3.2—Package Server Agent Upgrade Collection
The Windows Computers requiring Altiris Package Server Agent Upgrade collection that applies, by default, to the Windows Package Server Agent Upgrade Software Delivery task has been modified.
Previously, the collection didn’t check for Altiris Agent Version 6.0.2338 (SP3) or higher. This resulted in the SP2 Altiris Agent Version 6.0.1508 being eligible for the SP3 Package Server Agent Upgrade. The SP3 Package Server Agent requires an installed Altiris Agent Version SP3, so, if the Package Server Agent is upgraded before the Altiris Agent then both will be unusable.
3.3 — New Registry key for disabling Package Server directory security
A new Package Server registry key, EnableDACLManagement, has been created to allow you to change how a Package Server manages the security on its packages.
By default, a Package Server manages its packages by setting specific permissions on package directories; this includes overriding any custom permissions you may have set on the directories. When this registry key is activated, Package Server will no longer override existing permissions on package directories.
Take care when using this key as incorrect permissions could potentially render the Package Server directories inaccessible to the Package Server and Altiris Agents.
To ensure a fully functional Package Server, full control for Local Administrator and System need to exist on all package directories in addition to any other custom permissions.
Normally, Altiris Agents and other Package Servers access the packages located on the Package Server computer using the Agent Connectivity Credential (ACC), configured on the Notification Server. To ensure they continue to download packages, configure the Everyone or ACC account with read and execute privileges on the package directories. This is required because when the key is activated, Package Server is instructed not to manage permissions, which includes not applying the ACC or Everyone account to the downloaded packages.
To create the Registry Key
As the registry key does not exist on a default install of the updated Package Server, create the DWORD key, 'EnableDACLManagement' under the following location in the registry—HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Package Server. Before creating the key, stop the Altiris Agent Service and restart when finished.
The registry key can have one of the following settings:
· 0—Ensures that Package Server will not change existing security on package directories.
· 1—Will cause Package Server to function as normal by applying and resetting permissions on package directories.
--------------------------------------------------------------------------------
Environment
Notification Server 6.0 SP3 version 6.0.6074
Altiris Agent required—SP3 version 6.0.2338
The updated Package Server is not compatible with Altiris agent versions earlier than 6.0.2338
Cause
Software bug.
Resolution
This update, when installed on Notification Server SP3, replaces the existing Package Server Agent package, with an updated version. Package Servers within your environment will need to be upgraded to this version for any changes contained in the update to apply. Uninstalling the update on the Notification Server will restore the original SP3 version of the Package Server Agent package that existed prior to installing the update.
Important: Before upgrading your Package Servers to this updated version you must upgrade the Altiris Agent on your Package Servers to SP3 version 6.0.2338. The collection All Windows Computer Requiring Altiris Package Server Agent Upgrade, which applies by default to the Windows Package Server Agent upgrade task, will not contain Package Servers where the Altiris Agent version is lower than 6.0.2338 (SP3). Once the Altiris Agent has been upgraded on the Package Server, they will appear in this collection.
Section 1—Summary
This update, when installed on Notification Server SP3, replaces the existing Package Server Agent package. Package Servers in your environment need to be upgraded to this version for any update changes to apply. This update contains the following:
· Install, upgrade, and uninstall of Package Server Agent through Wise Installer. This was previously performed by Installshield.
· Registry key added to control whether or not the Package Server Agent can manage/change the security on its package directories.
· All Windows Computer requiring Altiris Package Server Agent Upgrade collection updated to only include Package Servers with Altiris Agent build 6.0.2338 (SP3), or greater.
Section 2—Installation
Name: Notification Server 6.0 SP3 Update 17613
Prerequisite software:
· NS build 6.0 SP3 Version 6.0.6074.
· Altiris Agent SP3 Version 6.0.2338 installed on Package Server.
IMPORTANT: The updated Package Server is not compatible with Altiris Agent versions earlier than 6.0.2338.
2.1—Install the Update
1. Download ftp://ftp2.altiris.com/Download/KB17613/Altiris_NS_6_0_SP3_KB17613.exe
to your Notification Server.
2. Run Altiris_NS_6_0_SP3_KB17613.exe.
2.2—Uninstall the Update
If, for any reason, you need to uninstall the update, the Notification Server will restore the original SP3 version of the Package Server Agent package. You can remove this via the ADD/REMOVE Programs option in the Control Panel on the Notification Server.
IMPORTANT: All updated Package Server Agents rolled out must be uninstalled before uninstalling the update on the Notification Server.
2.3—Upgrading Package Servers
The All Windows Computer Requiring Altiris Package Server Agent Upgrade collection that applies, by default, to the Windows Package Server Agent upgrade task, will not contain Package Servers with an Altiris Agent version lower than 6.0.2338 (SP3). Once the Altiris Agent has been upgraded on the Package Server, they will appear in this collection.
When the Windows Package Server Agent upgrade task is run, the upgrade will take approximately 15–20 seconds. Do not be concerned if the Altiris Agent does not start back up immediately after the upgrade task has run; this pause is expected.
Note: If the Package Server Agent is accidentally upgraded before the Altiris Agent, (which may happen if you are using a collection other than the All Windows Computer Requiring Altiris Package Server Agent Upgrade collection) the Altiris Agent and Package Server will not function or run Software Delivery tasks until the Altiris Agent has been upgraded to the required version. To do this, go to the Altiris Agent Installation page on the Notification Server and push out the Altiris Agent to the computer. This will carry out an upgrade of the installed Altiris Agent, and both the Altiris Agent and Package Server will then function normally.
Section 3—New Features and Enhancements in this Update
3.1—Package Server using Wise Installer
The install, upgrade and uninstall of the Package Server Agent is now done by Wise Installer; it was previously done by Installshield. There is a known issue with Installshield Version 10.5 that causes installations to fail on some systems with terminal services enabled with the following error message:
An Error (-5006 : 0x80004005) has occurred while running the setup. Please make sure you have finished any previous setups and closed other applications. If the error still occurs, please contact your vendor: Altiris.
For information, see http://community.installshield.com/showthread.php?threadid=109023
3.2—Package Server Agent Upgrade Collection
The Windows Computers requiring Altiris Package Server Agent Upgrade collection that applies, by default, to the Windows Package Server Agent Upgrade Software Delivery task has been modified.
Previously, the collection didn’t check for Altiris Agent Version 6.0.2338 (SP3) or higher. This resulted in the SP2 Altiris Agent Version 6.0.1508 being eligible for the SP3 Package Server Agent Upgrade. The SP3 Package Server Agent requires an installed Altiris Agent Version SP3, so, if the Package Server Agent is upgraded before the Altiris Agent then both will be unusable.
3.3 — New Registry key for disabling Package Server directory security
A new Package Server registry key, EnableDACLManagement, has been created to allow you to change how a Package Server manages the security on its packages.
By default, a Package Server manages its packages by setting specific permissions on package directories; this includes overriding any custom permissions you may have set on the directories. When this registry key is activated, Package Server will no longer override existing permissions on package directories.
Take care when using this key as incorrect permissions could potentially render the Package Server directories inaccessible to the Package Server and Altiris Agents.
To ensure a fully functional Package Server, full control for Local Administrator and System need to exist on all package directories in addition to any other custom permissions.
Normally, Altiris Agents and other Package Servers access the packages located on the Package Server computer using the Agent Connectivity Credential (ACC), configured on the Notification Server. To ensure they continue to download packages, configure the Everyone or ACC account with read and execute privileges on the package directories. This is required because when the key is activated, Package Server is instructed not to manage permissions, which includes not applying the ACC or Everyone account to the downloaded packages.
To create the Registry Key
As the registry key does not exist on a default install of the updated Package Server, create the DWORD key, 'EnableDACLManagement' under the following location in the registry—HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Package Server. Before creating the key, stop the Altiris Agent Service and restart when finished.
The registry key can have one of the following settings:
· 0—Ensures that Package Server will not change existing security on package directories.
· 1—Will cause Package Server to function as normal by applying and resetting permissions on package directories.
--------------------------------------------------------------------------------
Environment
Notification Server 6.0 SP3 version 6.0.6074
Altiris Agent required—SP3 version 6.0.2338
The updated Package Server is not compatible with Altiris agent versions earlier than 6.0.2338
Cause
Software bug.
Resolution
This update, when installed on Notification Server SP3, replaces the existing Package Server Agent package, with an updated version. Package Servers within your environment will need to be upgraded to this version for any changes contained in the update to apply. Uninstalling the update on the Notification Server will restore the original SP3 version of the Package Server Agent package that existed prior to installing the update.
Important: Before upgrading your Package Servers to this updated version you must upgrade the Altiris Agent on your Package Servers to SP3 version 6.0.2338. The collection All Windows Computer Requiring Altiris Package Server Agent Upgrade, which applies by default to the Windows Package Server Agent upgrade task, will not contain Package Servers where the Altiris Agent version is lower than 6.0.2338 (SP3). Once the Altiris Agent has been upgraded on the Package Server, they will appear in this collection.
11 April 2006
Unable to get the config XML for the specified item (With DeleteAnItem.cs as stext)
Orphaned objects in the database will cause these messages. The GUIDs displayed in the log errors frequently point to the "Software Deliver Agent Install" object and have been traced to uninstalling and then reinstalling Software Delivery and the "Software Deliver Agent Install" object not properly being removed.
--------------------------------------------------------------------------------
Resolution
Complete the following:
To remove an orphaned object from the Notification Server tree use the following script:
nscript.exe deleteanitem.cs
and this will delete the object associated with this GUID. Always validate the GUID before removing it. This can be done by the following steps:
a. Open SQL Query Analyzer.
b. Make sure that you select the correct database, i.e. Altiris.
c. Type the following: select * from vitem where guid like ''
If it does not show, then go ahead and complete step 1.
Note: The nscript.exe file is found on the Notification Server in ...\program files\altiris\notification server\bin. The deleteanitem.cs file must be created and the blue part at the end of this article must be pasted in that file.
(Optional) If the script in step 1 does not remove the NS tree object, then there is likely an association that needs to be removed. This can be done with the following script:
delete from ItemReference where hint = 'policyappliestocollection' and ParentItemGuid =
this is DeleteAnItem.cs (Copy and paste the code)
using System;
using System.IO;
using Altiris.NS.ItemManagement;
using Altiris.NS.Security;
class MyScriptClass
{
static void Main( string[] args )
{
//
// Set the context for the current user
//
SecurityContextManager.SetContextData();
Guid itemGuid = Guid.Empty;
try
{
itemGuid = new Guid( args[ 0 ] );
}
catch( FormatException )
{
throw new ApplicationException( "Must pass a GUID as an argument" );
}
//
// Get the collection item
//
IItem itemToExport = Item.GetItem( itemGuid ) ;
if( null == itemToExport )
throw new ApplicationException( "The GUID does not match an item" );
itemToExport.Delete();
//
// Export the item
//
}
}
--------------------------------------------------------------------------------
Resolution
Complete the following:
To remove an orphaned object from the Notification Server tree use the following script:
nscript.exe deleteanitem.cs
and this will delete the object associated with this GUID. Always validate the GUID before removing it. This can be done by the following steps:
a. Open SQL Query Analyzer.
b. Make sure that you select the correct database, i.e. Altiris.
c. Type the following: select * from vitem where guid like '
If it does not show, then go ahead and complete step 1.
Note: The nscript.exe file is found on the Notification Server in ...\program files\altiris\notification server\bin. The deleteanitem.cs file must be created and the blue part at the end of this article must be pasted in that file.
(Optional) If the script in step 1 does not remove the NS tree object, then there is likely an association that needs to be removed. This can be done with the following script:
delete from ItemReference where hint = 'policyappliestocollection' and ParentItemGuid =
this is DeleteAnItem.cs (Copy and paste the code)
using System;
using System.IO;
using Altiris.NS.ItemManagement;
using Altiris.NS.Security;
class MyScriptClass
{
static void Main( string[] args )
{
//
// Set the context for the current user
//
SecurityContextManager.SetContextData();
Guid itemGuid = Guid.Empty;
try
{
itemGuid = new Guid( args[ 0 ] );
}
catch( FormatException )
{
throw new ApplicationException( "Must pass a GUID as an argument" );
}
//
// Get the collection item
//
IItem itemToExport = Item.GetItem( itemGuid ) ;
if( null == itemToExport )
throw new ApplicationException( "The GUID does not match an item" );
itemToExport.Delete();
//
// Export the item
//
}
}
DS Console slow?
From Microsoft KB article:http://support.microsoft.com/kb/296264/
By default, opportunistic locking is enabled for server message block
(SMB) clients that run one of the Windows operating systems that is
listed at the beginning of this article. Opportunistic locking allows
clients to lock files and locally cache information without the risk of
another user changing the file. This increases performance for many file
operations but may decrease performance in other operations because the
server that grants the opportunistic lock must manage the breaking of
that lock when another user requests access to the file.
On dedicated servers running Windows 2000 Professional, Server, Advanced
Server, or Windows XP Professional, create the following
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parame
ters
Create the following:
Value Name: EnableOplocks
Data Type: REG_DWORD
Parameter Value: 0 Hex (False)
(If your server is not a dedicated server you will also need to create
the workstation keys listed below.)
On workstations with Windows 2000 Professional, or Windows XP
Professional, in this key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\P
arameters
Create the following:
Value Name: UseLockReadUnlock
Data Type: REG_DWORD
Parameter Value: 0 Hex (Disabled)
Value Name: UseOpportunisticLocking
Data Type: REG_DWORD
Parameter Value: 0 Hex (Disabled)
Value Name: UtilizeNtCaching
Data Type: REG_DWORD
Parameter Value: 0 Hex (Disabled)
Reboot all servers and clients affected
REF : Forum
By default, opportunistic locking is enabled for server message block
(SMB) clients that run one of the Windows operating systems that is
listed at the beginning of this article. Opportunistic locking allows
clients to lock files and locally cache information without the risk of
another user changing the file. This increases performance for many file
operations but may decrease performance in other operations because the
server that grants the opportunistic lock must manage the breaking of
that lock when another user requests access to the file.
On dedicated servers running Windows 2000 Professional, Server, Advanced
Server, or Windows XP Professional, create the following
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parame
ters
Create the following:
Value Name: EnableOplocks
Data Type: REG_DWORD
Parameter Value: 0 Hex (False)
(If your server is not a dedicated server you will also need to create
the workstation keys listed below.)
On workstations with Windows 2000 Professional, or Windows XP
Professional, in this key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\P
arameters
Create the following:
Value Name: UseLockReadUnlock
Data Type: REG_DWORD
Parameter Value: 0 Hex (Disabled)
Value Name: UseOpportunisticLocking
Data Type: REG_DWORD
Parameter Value: 0 Hex (Disabled)
Value Name: UtilizeNtCaching
Data Type: REG_DWORD
Parameter Value: 0 Hex (Disabled)
Reboot all servers and clients affected
REF : Forum
07 April 2006
License Removal Tool not working for NS6.0 SP3
[quote]--------------------------------------------------------------------------------
Problem
The License Removal Tool is not working to remove licenses (in NS6.0 SP3) that were installed in SP2 before the upgrade to SP3.
--------------------------------------------------------------------------------
Environment
NS 6.0 SP3
--------------------------------------------------------------------------------
Cause
The naming of the licenses have changed from Computing Edge to Altiris Licensing. The license removal tool has a static pointer to the Computing Edge certificates and does not detect the new storage location of licenses with SP3.
--------------------------------------------------------------------------------
Resolution
This has been reported as a bug for the license removal tool.
Workaround:
To manually remove licenses without the license removal tool, you can perform the following steps:
1- Start > Run > MMC.
2- Choose File > Add/Remove Snap-in.
3- Choose Add and highlight Certificates, then click Add.
4- Choose the radio button for " Computer account" , then click next.
5- Leave the default of " Local computer: .." , and click finish.
6- Close the Add Snap-in dialog box.
7- Click ok to apply the settings.
8- Highlight the Certificates folder under the Altiris Licensing to see the installed certificates.
If you remove all license certificates in this window, it will remove all licensing from the Notification Server similar to the way the license removal tool did. If you do not need to remove everything, you can find a specific license that will need to be removed by opening each license certificate and viewing the details (see below):
**Note: Once the licenses have been removed from the Microsoft Certificate Store, you will need to refresh the licensing page within the Notification Server for the results to show.
[/quote]
Problem
The License Removal Tool is not working to remove licenses (in NS6.0 SP3) that were installed in SP2 before the upgrade to SP3.
--------------------------------------------------------------------------------
Environment
NS 6.0 SP3
--------------------------------------------------------------------------------
Cause
The naming of the licenses have changed from Computing Edge to Altiris Licensing. The license removal tool has a static pointer to the Computing Edge certificates and does not detect the new storage location of licenses with SP3.
--------------------------------------------------------------------------------
Resolution
This has been reported as a bug for the license removal tool.
Workaround:
To manually remove licenses without the license removal tool, you can perform the following steps:
1- Start > Run > MMC.
2- Choose File > Add/Remove Snap-in.
3- Choose Add and highlight Certificates, then click Add.
4- Choose the radio button for " Computer account" , then click next.
5- Leave the default of " Local computer: .." , and click finish.
6- Close the Add Snap-in dialog box.
7- Click ok to apply the settings.
8- Highlight the Certificates folder under the Altiris Licensing to see the installed certificates.
If you remove all license certificates in this window, it will remove all licensing from the Notification Server similar to the way the license removal tool did. If you do not need to remove everything, you can find a specific license that will need to be removed by opening each license certificate and viewing the details (see below):
**Note: Once the licenses have been removed from the Microsoft Certificate Store, you will need to refresh the licensing page within the Notification Server for the results to show.
[/quote]
Subscribe to:
Posts (Atom)