You may experience slow performance when you run 32-bit SQL Server tools on 64-bit operating systems
When you install 64-bit editions of Microsoft SQL Server 2005, the following 32-bit versions of the following tools are installed:• SQL Server Management Studio • SQL Server Configuration Manager • Database Engine Tuning Advisor When you run these tools on 64-bit operating systems, the tools run in the Windows on Windows (WOW) environment. Under certain conditions, you may experience slow performance when you run these tools. To improve performance, run these 32-bit tools on a computer that is running a 32-bit operating system. Then, connect to a 64-bit server that is running SQL Server.
http://support.microsoft.com/default.aspx?scid=kb;en-us;906892

How to use SQL Server Business Intelligence Development Studio or the dtutil utility to regenerate the package ID of an SSIS package that was duplicated
In Microsoft SQL Server 2005 Integration Services (SSIS), a 16-byte GUID is generated and stored as the PackageID property of a SSIS package when the SSIS package is created. After you run the package, you can write the package ID to a log file by using the SSIS log provider. This package ID differentiates log entries for different packages. However, the following behavior may occur:• When an SSIS package is copied in a file system, the new copy contains the same package ID as the original SSIS package. • You can successfully run the package that has the same package ID. However, you cannot differentiate the two packages by using the logging data because the package IDs are the same. To regenerate a new package ID for each package, use one of the methods that are described in the "More Information" section.
http://support.microsoft.com/default.aspx?scid=kb;en-us;906564

How to use the dtutil utility (Dtutil.exe) to set the protection level of a batch of SQL Server Integration Services (SSIS) packages in SQL Server 2005
Microsoft SQL Server 2005 Integration Services (SSIS) implements security on the client computer and on the server computer when you deploy SSIS packages. You can encrypt the packages to keep the packages' property values secret by setting the protection level of the packages. Packages include the ProtectionLevel property. You can set the ProtectionLevel property according to the level of protection that a package requires.

For example, in a team development environment, a package can be encrypted by using a password that is known to the team members who work on the package. You can easily set a password by using SQL Server Business Intelligence Development Studio or by using the dtutil utility (Dtutil.exe) for a single package. However, if you have to handle lots of packages, the best method is to use the dtutil utility to set the protection level of a batch of SSIS packages. You can generally put a list of individual commands for each package in a .bat file or in a .cmd file and then run the file. If the packages are stored in the same folder, you can use short commands to loop the batch of packages in that folder.
http://support.microsoft.com/default.aspx?scid=kb;en-us;906562

How to interpret data that is logged by using a SQL Server 2005 Integration Services log provider
Microsoft SQL Server 2005 Integration Services (SSIS) uses the Execute Package task to support a parent-child package relationship. The Execute Package task is one of the available control flow objects in an SSIS project. You can use the Execute Package task to call another package as part of a work flow. An SSIS package can use an SSIS log provider to log event information. When a parent package executes, the SSIS log data is logged from two SSIS log providers, the child package and the parent package. This article discusses how to interpret data that is logged by using a SQL Server 2005 Integration Services log provider. The article also contains information to help you develop queries that are based on the logged data.
http://support.microsoft.com/default.aspx?scid=kb;en-us;906563

Description of SOAP interoperability issues that may occur when you use the Systinet Web Application Services Platform (WASP) 4.6 development toolset together with native HTTP SOAP support in SQL Server 2005
The native HTTP SOAP support that is introduced in Microsoft SQL Server 2005 lets you enable the Transact-SQL programmability of SQL Server as Web methods. For example, you can enable the stored procedures or the user-defined functions as Web methods. This functionality lets SQL Server 2005 become available as a SOAP 1.2-compliant server. A SOAP 1.2-compliant server is reachable over HTTP by both SOAP 1.1 clients and SOAP 1.2 clients. This article describes SOAP interoperability issues that may occur when you use the Systinet Web Application Services Platform (WASP) 4.6 development toolset to develop and maintain SOAP client applications.
http://support.microsoft.com/default.aspx?scid=kb;en-us;894711