In this article we'll be taking a look at setting up a SDL Tridion .NET deployment environment. SDL Tridion gives you many options for deployment and methods for getting your data to your web servers. Tridion supports multiple web servers including Apache and IISas well as multiple methods to transfer data include HTTP(s), FTP, Local File System, SFTP, and SSHFTP. Looking at that list we can immediately see the cross platform and extensibility options for our environments. For the purpose of this article I'm going to keep it Microsoft technology, but feel free to explore all the options listed above to find out which method is best for your environment and requirements.

Prerequisites

• SDL Tridion Installed in a development environment
• IIS (Version 7 is used in this article)
• .NET version 4 installed

For this article we need a working Tridion environment (a development environment will work perfect). If you need assistance setting one up, please refer to the following:

http://www.sdltridionworld.com/articles/sdltridion2011/tutorials/creating-development-vm-1.aspx

Getting Ready

To be sure we're ready for the deployment server let's make sure we have the prerequisites above, a working IIS Server with SDL Tridion installed, and .NET version 4, the rest we'll be setting up and configuring below.
We're going to need a site to publish our pages to, so let's start by opening IIS, and setting up a basic site, you can use the following settings:
Sitename: Deployment_Test
Physical Path: C:\Inetpub\Deployment_Test (you can point it somewhere else to better fit your own environment)
IP Address: Let's keep it "All Unassigned" and use localhost
Port: 8080 (Or a port of your choosing if 8080 is in use)

Once you click "OK" with the above settings you should hav

Preparing your new site to be published to

Now that we have a basic site setup in IIS, we need to give it the necessary libraries and configuration to run as a Tridion http instance or Content Deployer that can accept files we publish to it. You can think of this site as an intermediary between your CME and a display site (such as a development, staging or live environment) that deploys your pages and files.
Let's first locate the necessary files to include in this instance; they should be in your Tridion folder under Program Files from your install.
In the root location, create a bin\ subdirectory.
Copy the following assemblies, located in c:\Program Files [*(x86)]\Tridion\bin, to the bin folder of your Web application:e a blank new Website in IIS.

• netrtsn.dll
• xmogrt.dll
• Tridion.ContentDelivery.dll
• Tridion.ContentDelivery.Configuration.dll
• msvcr71.dll
• msvcp71.dll

*If you are installing on a 64-bit machine using a 64-bit JDK, you do not need the msvcr71.dll and msvcp71.dll assemblies.
*For 64 bit installations
To remove the recycling of the IIS worker process:

• Go into IIS and view your Application Pools
• Click on the site's Application Pool you just created
• Click on Advanced Settings on the right
• Change the Regular Time Interval to 0
• Click OK

We're going to need a receiver for the HTTP(s) deployer to accept files we publish from our CME, to do this we need to copy an ASPX file into the root of our newly created deployment instance. The file should be located in your installer CD or directory under "Content Delivery\windows\httpupload" called HTTPUpload.aspx.

Finally we need a basic Web.config file in the root for our deployment site, create a new one via your favorite text editor or Visual Studio, here's a sample:

<?xml version="1.0" encoding="utf-8" ?>
  <configuration>
    <system.web>
         <compilation defaultLanguage="c#" debug="true" />
     </system.web>
</configuration>

Your site directory should now look like the following:

Giving ourselves the ability to run multiple instances

Now we have the basics, however, if you want to run multiple instances and avoid future headaches we should give our deployment instance its own configuration that won't affect other sites (and its best practices to do this, even if for now you're just planning on one instance). To do this we need to copy a few more files from our Tridion program files directory. Earlier we placed files in our "Bin" directory, we now need to create an additional 2 sub directories under here called "lib" and "config"
1. Copy the following files located in c:\Program Files\Tridion\config to the config folder of your Web application:

• cd_storage_conf.xml
• cd_deployer_conf.xml
• cd_link_conf.xml
• cd_wai_conf.xml
• cd_dynamic_conf.xml
• cd_monitor_conf.xml
• logback.xml

2.  Edit the configuration files, for each Content Delivery instance, so that they refer to their own directories, data stores, log files, and so on. Refer to Configuring Content Delivery on the Content Delivery server.
3.  In the logback.xml file, ensure that the logging location is configured to log to a directory outside of the Web application. Refer to Configuring logging on the Content Delivery server.
4.  Copy the following SDL Tridion JAR files, located in c:\Program Files\Tridion\lib, to the lib folder under bin of your Web application:

• cd_broker.jar
• cd_cache.jar
• cd_core.jar
• cd_datalayer.jar
• cd_deployer.jar
• cd_dynamic.jar
• cd_linking.jar
• cd_model.jar
• cd_monitor.jar
• cd_tcdl.jar
• cd_wai.jar

5.  Copy the following third-party JAR files, located in c:\Program Files\Tridion\lib, to the lib folder under bin of your Web application:

• activation.jar
• antlr.jar
• aopalliance.jar
• asm.jar
• axis-jaxrpc.jar
• axis.jar
• commons-codec.jar
• commons-collections.jar
• commons-dbcp.jar
• commons-httpclient.jar
• commons-pool.jar
• dom4j.jar
• easylicense.jar
• ejb3-persistence.jar
• hibernate-annotations.jar
• hibernate-commons-annotations.jar
• hibernate-core.jar
• hibernate-entitymanager.jar
• hibernate-validator.jar
• jaxb-api.jar (only copy this file if you use Java 5, or if you use IBM Java. IBM WebSphere uses IBM Java by default.)
• jaxb-impl.jar (only copy this file if you use Java 5, or if you use IBM Java. IBM WebSphere uses IBM Java by default.)
• javassist.jar
• jdbcpool.jar
• jsr311-api.jar
• jta.jar
• logback-classic.jar
• logback-core.jar
• persistence-api.jar
• serializer.jar (do not copy this file if your Web Application server is RedHat JBoss Enterprise Application Platform 4.3 or 5.0)
• slf4j-api.jar
• snmp4j.jar
• spring-aop.jar
• spring-asm.jar
• spring-beans.jar
• spring-context-support.jar
• spring-context.jar
• spring-core.jar
• spring-expression.jar
• spring-jdbc.jar
• spring-orm.jar
• spring-tx.jar
• stax-api.jar (do not copy this file if your Web Application server is RedHat JBoss Enterprise Application Platform 4.3 or 5.0 or Oracle WebLogic Server 10g Release 3 or 11g Release 1)
• xalan.jar (do not copy this file if your Web Application server is RedHat JBoss Enterprise Application Platform 4.3 or 5.0)

6. Important: What we're creating is an instance of a "content deployer" that lives in IIS. Therefore in order for this to work, we must stop the Tridion Content Deployer Windows Service. If we try to use both deployers they will be conflicts and you will receive errors while deploying.

Confirm your 'Development' instance

To recap, we have now setup an http(s) transfer instance or a content deployer in IIS which we can publish to from our CME.

Before we start to do this, I want to reemphasize how important Step 2 was in the previous section. We're going to need somewhere for our files and pages to end up! This would be your development or staging site on the same server. If you haven't created one yet or didn't already have something you were testing with, now would be a good time to setup a new basic site in IIS.

Assuming you don't have a site yet that you want to publish to yet, let's go into IIS again and create a basic one with the following settings:

Sitename: Development_Test

Physical Path: C:\Inetpub\Dev (you can point it somewhere else to better fit your own environment)

IP Address: Let's keep it "All Unassigned" and use localhost

Port: 8081 (Or a port of your choosing if 8081 is in use)

Click "OK" and your development site should be created for you in IIS. Referring to Step 2 in the previous section again we need to change the configuration file to write to this newly created site.

Open the file: C:\Inetpub\Deployment_Test\bin\config\cd_storage_conf.xml (assuming you followed my directory structure) in your favorite text editor. On approximately line 53 you should see the start of the "Storage" section/tags. For the purpose of this tutorial please comment out all items within this section so there isn't any confusion about where the files are going, or what we're using for storage.

Once those are commented out, we can add our own locations.  To match what we've done so far, there are two entries that we will need to add in this section:

<Storage Type="filesystem" class="com.tridion.storage.filesystem.FSDAOFactory" Id="wwwroot" defaultFilesystem="false">
     <Root Path="c:\inetpub\Dev" />
</Storage>
<Storage Type="filesystem" class="com.tridion.storage.filesystem.FSDAOFactory" Id="wwwdata" defaultFilesystem="true" defaultStorage="true">
     <Root Path="c:\inetpub\wwwdata" />
</Storage>

The first entry tells us where the end result for our pages will be, the Development_Test site we setup earlier. The second entry we will need to create a directory for under C:\Inetpub called wwwdata, and this folder will house our metadata since we're using file system and not a database.

Important: For Tridion components to work, we must copy the bin directory from our Deployment_Test to the root of our Development_Test folder (C:\Inetpub\Dev)

Important: For the directories we setup, we must set permissions for access otherwise you'll get right access errors in your logs and won't be able to publish. The same user that is running your Application Pool must have read access to these directories, as well as write access on wwwdata.

Now that we have our deployer and development sites configured, restart the Deployment_Test Application Pool in IIS to ensure it's ready for use.

Publishing

At this point we should have all we need for our server configuration. Now we need to test it! To do this we need to setup our CME to recognize our new HTTP deployer as a target. Open up your CME, and let's get started.
With your CME open click Administration in the lower left, and then click Target Types, it should look like the following:

Right click in the window to the right and choose new Target Type
Name: IIS Deployer
Description: IIS Deployer

After you fill in the two fields, click Save and Close.
Next we need a Publication Target, click 'Publication Targets' on the tree to the left and you should see:

Again, lets right click in the window to the right, and choose New Publication Target, we should get the following screen:

The settings above are as follows and should be accurate assuming all the paths you input have followed this tutorial:
Name: IIS Deployer
Description: Deployer for IIS HTTP
Target Language: ASP.NET
Default Code Page: System Default
Minimal Approval Status: (None)
Priority: normal

Destinations:

You will need to add a destination, this points to the HTTPUpload deployer we setup earlier in IIS.
Destination Name: IIS
Protocol: HTTPS
Login: a (this would need to be a real value if you setup authentication in IIS for your deployer site)
Password: a (this would need to be a real value if you setup authentication in IIS for your deployer site)
Fully specified URL to upload page: http://localhost:8080/HTTPUpload.aspx

Time to test!

I've prepared a final checklist for you to review that should summarize what you've done above, you should make sure the following is complete in order to see a working example of your site deploying to IIS.

• Working basic Tridion instance (CME)
  • Setup publication options, target and type
• HTTP Deployer
  
  • Copied HTTPUpload.aspx
  • Copied files to bin
  • Copied jar files in lib under bin
  • Copied and modified config files in config under bin
  • Necessary changes to application pool
  • Optional: Any authentication settings

• Display Site