YThe Central Web Site Management (www.uwyo.edu/centralsiterequests) utilities provide request forms to get site work accomplished as efficiently as possible. These forms can be used to perform the following tasks:

• Create new sites (including Recognized Student Organization sites)
• Delete existing sites
• Modify management and authoring of sites (by UWYO domain account)
• Modify users allowed to browse restricted sites (by UWYO domain account)
• Lookup Site Configuration Information
• Request DNS Hosted Sites (**Fees required)
• Request WWW site redirect work
• Request database DSN work
• Request site configuration changes
• Request site quota changes (**Fees required for increases)
• Efficiently contact Information Technology about other site requests

There are a variety of ways to get help with your entity's Web site:  

1. The AskIT Web site (www.uwyo.edu/askit) provides multiple how-to and FAQ documents for UW Web site development as well as links to other Web development online resources.
    
2. The University of Wyoming Web News site (www.uwyo.edu/webnews) provides resources to help you develop and manage your UW Web site.
    
3. University Public Relations provides institutional web services on an appointment basis. See the University Public Relations Institutional Web Services (www.uwyo.edu/publicrelations/web/) for more information.
    
4. IT provides training opportunities to UW faculty and staff on a variety of topics and for a variety of applications used at UW. See the IT Training Web site (www.uwyo.edu/infotech/training) for more information.
    
5. If you are unsure of the services or support offered, the best initial contact for anything computer related, including your Web sites, is the IT Help Desk at 766-HELP, option 1, or userhelp@uwyo.edu. They can help determine the best path for your question or request and route it accordingly to get it resolved as efficiently as possible.

Yes.  

Web development best practices dictate that a Web site be created and edited separately from the production or live instance of the Web site. To accomplish this, and to avoid the necessity for Web developers to run a personal Web server on their own desktop computer (which puts the desktop computer and the rest of campus at risk),  a development environment is provided on the UW central Web servers to allow Web developers to create, edit, and test their Web site before publishing it to production. This acts as a quality assurance step, so that people browsing the Web can only get to the production site once it is complete and correct.

IT, in conjunction with University Public Relations, provides a development Web server for all UW sites that are centrally housed. The development server offers both basic and FrontPage-extended sites in the same environment as is provided on the production servers, WWW, UWACADWEB, and UWADMNWEB. This allows for a mirror image of the production site to be created in development and vice versa.  Any entity that has a site on one of the production servers can also have a development site. The development site can have the same or different authors as the production site. Requesting different authors for the development site than for the production site allows you to create a quality assurance (QA) process: you can determine separately who can create and edit the site in development versus who has the ability to complete a final review and then publish the site to production.

Access to the development server is restricted to computers within the UW firewall only, which prevents the outside world from being able to see these sites. The benefits of this restriction are twofold: it provides added security, so pages can be tested without having to worry as much about outside hackers accessing the server; and it keeps these development sites from being indexed by search engines such as Google, so pages that are in development are not available to the outside world to browse.

All regular Web sites created after April 5th, 2002 are created with both a production and development site. Author permissions will initially be set the same and can then be changed via the Central Web Site Management Requests site (www.uwyo.edu/centralsiterequests). All sites that existed prior to that date will not have a development site until a request is made for one. You can request a development Web site through the Central Web Site Management Requests site (www.uwyo.edu/centralsiterequests). Complete the steps to request a new site, and in the Site Purpose box, select DEVELOPMENT WEB SITE.

NOTE: Since this server acts as a development server for Web sites and Web projects, there may be times when it is necessary to take it down for short periods of time. This will normally be for a reboot of the server that takes about 10 minutes. A schedule is kept for the server on the Development Server Downtime Schedule page (www.uwyo.edu/Webnews/dev_server/devsched.htm), which will provide at least 2 hours advance notice if the server is to be rebooted at any time other than normal systems development time between 12 a.m. and 8 a.m. Sunday mornings.

IT maintains a standard naming convention for UW Web sites to lessen the affects of attacks to Web servers coming in with strings that contain non-standard characters. These standards will help to secure the UW Web servers as well as help to minimize problems with various Web software programs.  

Web site names can contain

• the standard set of characters A thru Z and numbers 0 thru 9
   
• the following non-standard characters only
    - (dash)
   _ (underscore)
   
• 18 characters or less

Web site names can not contain

• spaces

URL stands for Uniform Resource Locator. It is the address, name, or path used to get to a specific place or site on the Internet.  

When a UW Web site is created, a redirect is automatically created from the main university Web server, WWW, to the actual server where the site resides. A redirect is a way to automatically forward a requested site from a central server to the server where a site is actually located. All sites located on the UWADMNWEB or UWACADWEB servers have a redirect created so that every site on the UW central Web servers has a consistent URL in the format http://www.uwyo.edu/sitename. Redirects of this format can also be requested for Web sites that do not reside on one of the UW central Web servers.  

NOTE: Because WebCT is a program in itself that contains the class sites, a redirect from the WWW server cannot be created. Also, redirects cannot be created for FRONTIER Web sites.

At UW, Web site naming is standardized to make URLs easy to remember and as short as possible. At this time, the majority of UW sites can use the following naming convention regardless of what server the site physically resides on, as redirects have been setup for all sites:  

http://www.uwyo.edu/sitename, where sitename is the name of the Web site.

This naming convention will also help in the future. If any of the UW central Web servers have to be replaced and therefore renamed or it is necessary to change the name of an actual site, it will not be necessary to update the URL in all publications or to notify individuals of a site name change, as only the redirect will need to be updated so the same name will point to the new server or site name, and the move or change will be transparent to the end-user.

Microsoft FrontPage is a Web creation and management application that requires no programming knowledge but is robust enough for experienced Web site developers. FrontPage includes most of the features needed to publish a complex Web site.  

Individual Web pages are created, designed, and edited with the FrontPage program. As you add text, images, tables, form fields, and other elements to your page, FrontPage displays them as they would appear in a Web browser. FrontPage is easy to use because of its familiar word-processor style interface. You do not need to learn hypertext markup language (HTML) to use FrontPage because it creates the HTML code for you.

HTML code can be created and edited directly using FrontPage’s HTML view. In this view, you can enter text, edit HTML tags, script code, and use standard word-processing commands such as cutting, pasting, finding, and replacing.

Note: Microsoft replaced FrontPage with Expression Web in late 2006. Expression Web is similar to FrontPage.

The FrontPage Server Extensions are a set of programs installed on a Web server that support features such as collaborative authoring, hit counters, e-mail form-handling, and global hyperlink updates. FrontPage Server Extensions allow FrontPage to automate many operations that otherwise would have to be manually coded in HTML. UWADMNWEB, UWACADWEB, and WEBDEVFP are the UW central Web servers that provide FrontPage Server Extensions.

Due to Microsoft phasing out the support of FrontPage Server Extensions (FPSE), the Universitie's Central Web Services will no longer provide the option to create FrontPage extended sites.  FrontPage extensions will exist on the UW web server for the foreseeable future to service existing UW FrontPage extended sites. As of August 2009 a date for removal of FPSE from the UW web server has not been determined.

A Web form is a Web page that is designed to gather information from someone browsing your Web site. You can have a form submit information to a number of different mediums including having it e-mailed, writing it to a text file, or writing it to a database file among other options. Forms can be simple or sophisticated depending on the expertise of the person creating them.  

Microsoft FrontPage has a form wizard that will walk you through a question and answer session and will create a form based on the answers you provide. To access the form wizard, in FrontPage, select the File menu, and click New; in the Task Pane, in the New Page section, click More page templates; select the Form Page Wizard template, and click OK.

If the information you are going to be gathering is sensitive in nature, such as a Social Security Number, you will need to request an SSL secure site for the form to reside on. SSL uses a sophisticated algorithm to encrypt and decrypt data that is passed over the Internet. For further information on SSL, see What is SSL, and how can I use it? (www.uwyo.edu/askit/displaydoc.asp?askitdocid=637)

Instructions for setting up a form in FrontPage to send data to multiple files or e-mail recipients can be found at the following Microsoft Web pages:  

No, you do not have to use Microsoft FrontPage to create and edit your Web site. It is up to each entity to decide how best to manage their Web site. Web server environments are available for those who wish to use FrontPage and the capabilities available through the use of FrontPage Extensions as well as for those who choose to use other Web development applications.  

Many departments choose a FrontPage-extended site because of the ease of adding sophisticated Web components such as forms and searches without having to know any Web programming. Basic sites (non-FrontPage-extended) are provided on the WWW server that can be used with any other Web site development software available today. Be aware that if the software you choose requires function extensions similar to those behind FrontPage Extensions, they will not work, as the sites on the WWW server are basic only and do not provide this functionality.

If you are responsible for a site that was originally requested and setup on a FrontPage-extended server (UWADMNWEB or UWACADWEB) and you want to move it to a server that does not require the use of Microsoft FrontPage, please contact your IT user consultant. They can get the process started to move the site to the WWW server and convert it to a basic site. However, if the site has components that rely on the FrontPage Extensions, those components will no longer function once the site is moved to the basic server, and it will be the responsibility of each entity to fix these issues once the site has been moved.

Find information in the Microsoft Frontpage to Expression Web reference document.

Additional Expression Web resources

If you choose to upgrade to FrontPage 2003, you must also upgrade the rest of your Office Suite, specifically Microsoft Access, in order for you to be able to continue opening databases directly in FrontPage. There is a known issue with security settings that causes problems if you are running an older version of Microsoft Access with FrontPage 2003.

Each Web site is allocated 200MB of space free of charge. If an entity wants additional space beyond the 200MB limit, it is available in 50MB increments for $10 per year. Additional space can be requested through your IT user consultant (www.uwyo.edu/InfoTech/css/cssuser.htm).

Yes. UW sites can be restricted in one of two ways:  

NOTE: A site as a whole is either restricted or not. Certain directories within a site cannot be restricted while others are not restricted. If you need to restrict a specific directory within a site, you will need to request a new site, request that it be restricted, and then move the pages you want restricted to the new site.

1. Single username and password restriction: A specific username and password can be provided for each Web site, and the author of the site can give this information out to any individual they want to be able to browse the site. When an individual tries to browse to the site, they will be prompted to enter the username and password before they are able to see any of the pages within the site.
   
   The username will be created to match the name of the site (i.e. www.uwyo.edu/class5 would have a username of class5). The password can be determined by the author of the site.
    
2. Existing domain security group restriction: A site can be restricted to only allow members of an existing domain security group to browse the site. A site can be restricted to only allow browse access to individuals with a UWYO domain account, with either UWSTUDENTS or UWEMPLOYEES group affiliation, a specific college affiliation, or a specific department affiliation.
   
   NOTE: At this time, we do not create, populate, or manage domain security groups other than those recognized by Human Resources as a UW college or department.
   
   EXAMPLE
   
   Let's say the College of Business wants to have a Web site that only members of the College of Business, as defined by their work status in Human Resources, can browse. The site can be set up to ask for a user's UWYO domain username and password, which is checked against their domain account affiliation (what college or department the user is a member of), and the site will only allow those individuals that are current members of the College of Business (COB domain group) to browse the site.

1. Open Microsoft FrontPage.
    
2. Select the File menu, and click Open Site (or Open Web).
    
3. In the Open Site (or Open Web) window, in the Site name (or Web name) box, type the full URL of your development or production Web site in the format https://webdevfp.uwyo.edu/sitename, https://uwadmnweb.uwyo.edu/sitename, or https://uwacadweb.uwyo.edu/sitename, and click Open.
   NOTE: Notice the "s" in "https://". The "s" is necessary when opening a site through FrontPage.
    
4. When prompted for your username and password, enter your UWYO domain username and password, and click OK.

Access to a basic Web site on WWW or WEBDEV can be gained in one of two ways:  

1. You can access it via the LAN share by selecting the Start menu, selecting Run, and typing in \\www\sitename$ (or \\webdev\sitename$) or by mapping a network drive to \\www\sitename$ (or \\webdev\sitename$). See How to Map a Network Drive (www.uwyo.edu/askit/displaydoc.asp?askitdocid=239&parentid=1) for instructions on mapping a drive in Windows.
    
2. FTP can also be used to access a basic site on WWW and WEBDEV.
   Note:  FTP sites are not created by default for basic sites, they must be requested.  Please contact the IT Help Desk or your User Consultant.
   
   To gain access to a site on WWW via FTP, establish an FTP connection to www.uwyo.edu, and browse to your site.
   
   To gain access to a site on WEBDEV via FTP, establish an FTP connection to webdev.uwyo.edu, open WWW (or Databases), and browse to your site. NOTE: The method of accessing sites on WEBDEV via FTP will be changing to match that of WWW in the near future.
    
3. If you are using a Mac, please use the following instructions based on the location of your site:
   
   In the Go menu select Connect to Server. In the address field type the URL of your site using the following syntax:
   • for www.uwyo.edu use smb://longhorn.uwyo.edu/sitename$
   • for webdev.uwyo.edu use smb://hardcase.uwyo.edu/sitename$
   • for uwstudentweb basic sites use smb://rawhide.uwyo.edu/username$

You should name the homepage for your site one of the following: default.htm, default.html, or default.asp. These are the default documents that the Web server is setup to serve automatically.  

When you browse to a site and it says “Directory Listing Denied, This Virtual Directory does not allow contents to be listed” this means the root folder of the URL being browsed to does not have a default document in place and a specific file, if one exists needs to be specified.

Here are the default documents we support and their order if a file is not specified:

Default.htm
Default.html
Default.asp
Default.aspx
Index.htm
Index.html
Index.asp
Index.aspx

Yes. See the UW Public Relations Web Design Resources page (www.uwyo.edu/publicrelations/viscomm/) for more information.

Yes, IT will create a redirect from http://www.uwyo.edu/sitename to your server. If you have a Web site running on your own server and would like a redirect setup, e-mail the UW Webmaster at webmaster@uwyo.edu with the following information:  

• Full Name of Person Making Request
• Username of Person Making Request
• Phone Number of Person Making Request
• The URL of your current site / server (i.e. http://wwweng.uwyo.edu in the following example)
• The URL you would like on the UW central Web server to point to your site / server (i.e. http://www.uwyo.edu/engineering in the following example)

See the UW DNS Web Name Hosting FAQ (www.uwyo.edu/askit/displaydoc.asp?askitdocid=647&parentid=1).

To accommodate the request for statistics on Web sites located on the UW central servers, the following methods of providing these statistics are available.  

1. Statistics are available at http://webdev.uwyo.edu/web_statistics/
    
2. It is possible for more sophisticated users to access the entire Web site logs that are generated, copy them to their computer, and manipulate them any way they need to. Access to the Web site logs is gained via a LAN share: select the Start menu, click Run, and type \\servername\web_logs$\, where servername is the Web server your site resides on (WWW, UWADMNWEB, or UWACADWEB). You can then drill down to the specific log files you are interested in. Log files are kept for each individual virtual web server. Only Web logs for the previous six months will be kept, and if space becomes an issue, it may be necessary to decrease that timeframe in the future. 
    
3. Though statistical analysis is not provided for DNS hosted sites, access to the raw log files is provided for you to process manually. The share location for the files can be accessed by going to \\servername\web_logs$, where servername is the main part of your DNS hosted site's name. For example, if your site is named business.uwyo.edu, the share is \\business\web_logs$; if your site is named www.sixthmanclub.org, the share is \\sixthmanclub\web_logs$.

• If your site is a UW Content Management Site, go to http://webdev.uwyo.edu/web_statistics/ and click on the link "View UPR Content Management Broken Link Stats."
   
• If your site is not in the UW Content Management System, you can either:
  • contact UW Public Relations at www.uwyo.edu/publicrelations/web/ and they will provide you with a report,
    or
  • you can use a broken link checking program. A freeware program called XENU is available at http://home.snafu.de/tilman/xenulink.html or you can Google (or search the Internet using another search engine) for “XENU broken link checker.”

By default IE will replace the actual error messages coming from the server with a “friendly” error message, which hides the actual error contents.

To disable this feature and see the real error message coming from the server:

1. Go to Tools, Internet Options, and choose the Advanced tab.
2. Clear the Show friendly HTTP error messages checkbox and click OK. 
3. Close the browser, open it again, and re-request the page.

Contact a UW Public Relations staff web developer (www.uwyo.edu/publicrelations/staff/staff.asp).

WebCT is a powerful Web-based utility that can be used to either teach a class entirely online or, as it is more widely used on campus, can be used to supplement a class. WebCT includes such things as class e-mail, calendars, chats, whiteboards, quizzes, grades, outlines, and many other features.

WebCT courses are administered by the Ellbogen Center for Teaching & Learning. If you have any questions or comments about using WebCT, they can be contacted at Webct@uwyo.edu or through the Web site at www.uwyo.edu/ctl/contactus.

Yes. A data source name (DSN) can be created for your site to connect to a database. Additionally, FrontPage has database support built into the application, so you can use this option to easily setup database access for your FrontPage-extended Web site.

The drivers to allow the usage of Access 2007 Databases are available on the Web servers. This means that, if you have Access 2007, you can now use a database in this new format (.accdb) on your web site.  In order to have a DSN set up to use Access 2007 drivers:

• Please submit your request through https://uwadmnweb.uwyo.edu/centralsiterequests/ under Request Site Configuration Change
•  Check the box for Add or Remove External Data Access
•  In the text box labeled Please give a detailed explanation of any other changes you would like on this site or add additional information. Specify that you would like a DSN set up for ACCESS 2007.

No, DSN connection names cannot contain parenthesis.

(related topics include DAO & ODBC; see www.microsoft.com/data)

When you connect to a data source from a Web page, you do not connect directly to the source using its name; rather, you must use a data connection solution such as MDAC, which includes various ways to interact with a data source. Following are the basics of this functionality: 

• You have a data source (usually a database) that is stored in a location that is accessible to the users of your Web site.
• There is a data source name (DSN) either dynamically created with code that you have written or created for you on the server by the server administrator. This DSN is what you use in your scripted Web pages to interact with a data source.
• You write code, or use an editor such as FrontPage that automatically writes some of the code for you, to connect to the database, and you use code built into the data access component to make calls to functions that manipulate the database the way that you would like.

There are two methods that are widely used on campus and offered on the UW central Web servers, MDAC and the built-in FrontPage database access.

NOTE: For the purposes of explaining these options, we are assuming you are interacting with data from a database.

1. MDAC: This solution is for more experienced Web programmers who are familiar with interacting with a database via code or scripts such as Active Server Pages (ASP) or Java Script. When using this option, two areas of space are setup on the server. One area of space is for the actual Web pages (some of the pages will contain your code) and is accessible by persons browsing the Web with a standard Web browser. The other area of space is for the database file and is accessible by persons browsing the Web only by way of your coded pages that use the DSN created on the server during the initial setup. Under this structure, share level access is granted to the space where the actual database is stored, allowing you to have full access to the database without going through a Web browser. This method can be used in conjunction with a basic site that is located on the WWW server or from a FrontPage-extended site if you would rather not use the database functionality built into FrontPage.

   MDAC Structure (ODBC DSN connection)
   
   
    

2. FrontPage database access: This solution uses the built-in functionality of FrontPage to interact with a database, which does basically the same thing as the ODBC DSN connection; however, most of it is done automatically, so the Web author does not have to know all of the coding that is required on the backend (nor does the system administrator have to setup a DSN). When you create a form in FrontPage, you have a number of options of what to do with information once the Submit button (or whatever you use on your page) is clicked. One of the options is to send the information to a database. If you choose this option, FrontPage provides a wizard that will automatically create the FPDB folder in your site; create a Microsoft Access database in the folder with the name of the form it is associated with and populate a table in the database with the fields from your form; create a global .asa file in the root of the site that is used to automatically create the DSN; set permissions on the FPDB folder so that people browsing to the site cannot simply browse to the name of the database and download it to their computer (which is why it is important that all databases you use exist in the FPDB folder within your site. If they exist anywhere else, they are open to the world).

   FrontPage Database Structure
   
   

Listing of the DSN entries on the Web servers are not permitted for security reasons. To manually add a DSN to your FrontPage site,  

1. Open your FrontPage-extended site in Microsoft FrontPage.
    
2. Select the Tools menu, and click Site Settings (or Web Settings).
    
3. In the Site Settings (or Web Settings) window, select the Database tab, and click Add.
    
4. In the New Database Connection window, in the Name box, type a name that you would like to use for the database connection, select Custom definition, and click Advanced.
    
5. In the Advanced Connection Properties window, in the Connection string box, type the data source name (DSN) that was previously setup for you to use in the format DSN=DSNname, and click OK.
   NOTE: Instead of just the DSN name, you can define an entire DSN string just as you would in script, such as DSN=DSNname;DRIVER=(Microsoft Access Driver (*.mdb)) or DSN=DSNname;DRIVER=(Microsoft Access Driver (*.mdb,*.accdb)) for Access 2007 (See "Can I use an Access 2007 database with my Web Site?").
    
6. In the New Database Connection window, click OK.
    
7. In the Site Settings (or Web Settings) window, with the Database tab selected, click Verify.
    
8. Click Apply, and click OK to return to your site.

For additional information, see http://support.microsoft.com/default.aspx?scid=kb;en-us;285654.

SSE connection string example:

Provider=sqloledb;Data Source=BOUNTYHUNTER\RLDS,6008;UID=sa;Password=[YourPassword]

More information on SSE can be found at http://www.microsoft.com/sqlserver/2008/en/us/express.aspx

Resources:

• Definition of an SQL Injection
  (http://msdn.microsoft.com/en-us/library/ms161953.aspx)
• Preventing SQL Injections in ASP
  (http://msdn.microsoft.com/en-us/library/cc676512.aspx)
• Preventing SQL Injections in ASP.NET
  (http://msdn.microsoft.com/en-us/library/ms998271.aspx)
• Coding techniques for protecting against SQL Injection
  (http://forums.asp.net/t/1254125.aspx)
• Filtering SQL injection from Classic ASP
  (http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx)
• Input validation for security in Classic ASP
  (http://successontheweb.blogspot.com/2008/03/input-validation-for-security-in.html)

Yes. See the Web Calendar FAQ (www.uwyo.edu/askit/displaydoc.asp?askitdocid=652&parentid=1) for more information.

Yes. See the Streaming Media Server FAQ (www.uwyo.edu/askit/displaydoc.asp?askitdocid=676&parentid=1) for more information.

Yes. See the UW Google Search Engine FAQ (www.uwyo.edu/askit/displaydoc.asp?askitdocid=688&parentid=1) for more information.

Secure Sockets Layer (SSL) is a method of securing data communications that take place over the Internet between a person's Web browser and the site they are browsing to. SSL takes all data that is passed over the Internet, encrypts it on the sending side, and decrypts it on the receiving side. The encryption and decryption process is unique to the entities involved because of a handshaking process that takes place prior to any sensitive data being transferred.

SSL Encrypted support is offered on each of the central Web servers including WWW, UWADMNWEB, UWACADWEB, and UWSECUREWEB. Previously, SSL Encryption was only offered on UWSECUREWEB to provide the most secure environment possible; however, this environment was not very flexible. To offer a secure environment with a little more flexibility for Web authors, SSL Encryption is now available on all of the central Web servers.

For more information on SSL and SSL certificates see the SSL FAQ (www.uwyo.edu/askit/displaydoc.asp?askitdocid=697&parentid=1).

NOTE: If you would like to add an SSL logo to your page that can be clicked on to verify the SSL Certificate that the client is using, go to http://www.uwyo.edu/veri_seal/.

Before a site on the UWSECUREWEB will be created, you will need to read, sign, and submit the UWSECUREWEB and SSL Disclaimer (https://www.uwyo.edu/itsecuredocs/ssl/sslagreement0505.htm) to your IT user consultant or the IT Help Desk. Once this is done, you can request the site through your IT user consultant (www.uwyo.edu/InfoTech/css/cssuser.htm), the IT Help Desk, or through the Central Web Site Management Requests site (www.uwyo.edu/centralsiterequests). Complete the steps to request a new site, and in the Site Specific Request Details section, in the Should the site require SSL connections box, select Yes.  

For more information on SSL and SSL certificates see the SSL FAQ (www.uwyo.edu/askit/displaydoc.asp?askitdocid=697&parentid=1).

To help ensure that confidential information cannot be compromised, SSL is now required to be used wherever this type of information might travel across any networks. Previously, SSL was available but not mandatory; however, with the increasing availability of more sophisticated hacking tools, it has become necessary to make the use of SSL mandatory.

As of March 2005, the previous optional use of Secure Socket Layer (SSL) is now required on the UW central Web servers for the following types of sites:

• Sites requiring authentication to browse them - Sites that require a login to be able to browse / view them, require SSL (i.e. type https:// before the URL of the site). Browsing regular sites that do not require a login to access them are not affected by this change.
   
• Editing FrontPage Sites - In order to edit any FrontPage-extended site on WEBDEVFP, UWADMNWEB, UWACADWEB, and UWSTUDENTFPWEB, you must use SSL (i.e. type https:// before the URL of the site) to gain edit access to the site.

For more information on SSL and SSL certificates see the SSL FAQ (www.uwyo.edu/askit/displaydoc.asp?askitdocid=697&parentid=1).

Yes, the ASPEmail component is installed on all central Web servers. Go to www.aspemail.com for further information on the use of this component.

At this time, because of their close integration with the IIS Web Service and security, only Active Server Pages (ASP) scripting, .NET, and Java scripting are offered on the central Web servers.

No. Information Technology does not recommend or support the installation of Personal Web Server (PWS) or Internet Information Server (IIS) on a desktop computer. Inherently, running a Web service or an FTP service opens your computer up to everyone on the Internet, including all the hackers and hacker software that is out there. Additionally, Microsoft releases security patches and hot fixes frequently that are absolutely necessary to securing your computer. It can take a lot of time to fully research, test, and deploy these issues and patches. For these reasons, IT recommends that you use the UW central Web servers for your Web sites.

Only your department can decide if it is right for you to run your own server, as many factors come into play. One of the most important and most costly components of successfully running a server is the hiring of the proper personnel. This requirement is one that tends to get overlooked or grossly underestimated. Many times the responsibility is placed on a graduate student who may be gone in a year or added as a side task to the workload of a current employee with no server experience, with the assumption that once the server is setup, it will run reliably forever. However, a server requires attention on a daily basis throughout its lifecycle in order to keep it functional, with minimum downtime.  

Following is a brief overview of issues that must be addressed when running a server:

• Hiring personnel that are trained in all aspects of server management.
   
• Installing the operating system safely and properly - some viruses can infect a vulnerable (un-patched) computer in as little as 10 seconds after being connected to the network.
   
• Safely and properly installing and configuring any services the system may need.
   
• Configuring the security on the system properly, including file-level access, account management, and service lockdown.
   
• Evaluating and managing additional security concerns, including network protocol security and firewall configuration.
   
• Installing upgrades, including motherboard BIOS, peripheral BIOS, hardware, software, operating system, etc.
   
• Creating a backup system, including purchasing the backup hardware, planning a comprehensive strategy, defining a restore procedure, defining an offsite storage place, etc.
   
• Researching, testing, and installing patches, including hot fixes and security releases. This includes monitoring discussion and mailing lists, contacting manufacturers for updates, etc. This is one of the most important ongoing functions of running a server on campus. If your server is vulnerable and not patched, it is possible (and common) for your server to negatively impact the entire campus network.
   
• Providing a proper storage environment, including providing a climate-controlled, clean (the room should have air filters), secure room to store the server with networking installed, access to low distribution power units, access to emergency power supply, inclusion of a rack system that can make the addition or repair of hardware easier to accomplish (especially in multi-server environments), etc.
   
• Training, including initial and ongoing training on the operating system as it is constantly upgraded, ongoing training on the software installed on the system (most companies upgrade their software annually), training on hardware as it is upgraded, etc.
   
• Evaluating, installing, and configuring anti-virus software. 
   
• Installing and utilizing disk defragmenter software, which is a good idea to use on a server to keep it running as efficiently as possible.
   
• Monitoring, including performance monitoring, monitoring Event Logs for possible security breaches or problems, 24-hour monitoring for server up-time, 24-hour monitoring of room climate, etc.
   
• Alerting, including the implementation of a system to alert someone 24 hours a day if any of the systems being monitored are not working properly.
   
• Creating redundancy, including the redundant drive arrays and power supplies, the most common problems for servers. Someone needs to know and understand how the redundancy works, how the hardware works, and how to best utilize what it offers.
   
• Reporting, including creating a process to report prolonged out-of-service situations.
   
• Keeping up with changing hardware and software.
   
• Administering Maintenance Agreements, including the yearly purchase of Maintenance Contracts with both the OS vendor and the vendor of the software installed on the server.