I'm still dealing with the 'niceties' of the office and I'm getting targeted as not communicating well enough with people such as my CCB friend and possibly others. I've been communicating all of the things that they need to know for the most part and trying to leave out the technical mumbo jumbo, even if I told them about all of that they wouldn't tell me they don't understand...
I've completed combing through the ASP site for the php conversion and a few tweaks here and there. Currently I'm just waiting on ASP to give me the thumbs up for the transition to go live.
Currently the Drupal move has come to a halt with WEG's security check/complaints. Even though I addressed most of them they still are making it sound like Drupal is a huge Admin's nightmare which is definitely an over exaggeration:

Below is my response to some of WEG's concerns which are all in bullet points to help you find them. Although some of his concerns cannot be addressed currently, I think that a few of the bigger ones can be fixed with an extra module or code, specifically the https connection and the md5 hash password problem. I know your still going to review several other CMS's, but please take my comments into consideration as well. I still think Drupal is one of the better opensource content management systems out there, it just takes a little bit of a learning curve for the other web professionals to figure it out.
Have a nice day,
Miles
WEG wrote:

The short -
Drupal looks much better for users and web page developers than
it is for system administrators. It offers a lot of functions and I
have seen a number of impressive Drupal based websites.
However, it has a very bad security design and will be a nightmare to
maintain and upgrade. Parts of the maintenance and upgrade process
cannot be delegated to non-WEG teams, and it will require a significant
dedication of support time no matter what. If we absolutely have to be
stuck with Drupal, it should reside on a separate server and be wholly
separate from any server or database we use to support our existing
websites.
flame away, folks.
-----------------------
The long -
Drupal is called a Content Management System, but it is in fact a
code development platform with publishing and versioning features built
into it. Drupal relies on the Apache daemon having the ability to
modify files on a web server and uses a database for site administration
and holding some web page contents.
1 - PAM Authentication
At this point, PAM authentication does not work. It is not clear
exactly why, and we shouldn't assume that it can be done at any time
in the near future. It may be related to the fact that the PAM
extension was written for Linux PAM, not Solaris PAM.

* This would solve many of the login problems if there was a way to
get this to work. Also, Drupal 6 supports openID if that is
considered a safer way to login.

2 - General and Security
Drupal is written in Javascript and PHP with some shell scripts
for use as cron jobs. For advanced functions, it utilizes modules
that are not controlled by or the responsibility of the Drupal
development team. Some modules require additional software packages
which are not monitored by Drupal and so complicate the jobs of
installation, upgrading and patching. Although Drupal can serve up
plain HTML and PHP code, extensive use of its features is not directly
portable to other Content Management Systems and could require massive
rewrites in the future.

* The community is usually pretty good at keeping the modules up to
date, especially the ones that are used most frequently. And I'm
not sure that any CMS chosen by the WEG will play very nice with
any other outside CMS.
* I think that some modules for all CMS's will require some outside
software packages as things like TinyMCE (which is used by most)
is a software that is developed by an outside company
(http://tinymce.moxiecode.com/).

Configuration of multisite service is comparatively simple to setup.
There are various reasons to use single or multiple databases.
Although multisite is intended to reduce duplication and share code,
generally it would be better for UCAR organizational units to use
separate Drupal installations and databases for different websites.

* Although, this is great for me to use one central installation for
all four labs (SERE, ASP, CCB, and ISSE), because this will make
it much easier to have all of these sites in one central area with
all the modules in one central area. Plus you only have to place
the upgraded modules in one folder instead of worrying about
several different sites that need the upgrade.

The upgrade process is not designed for convenience. The
official Drupal philosophy is to not support backwards compatibility.
Modules are version specific, so that while a particular module
may support the new version of Drupal, they must be checked
manually and individually along with any supporting software. Web pages
written for Drupal must be checked for function and perhaps rewritten
when an upgrade occurs. The Drupal team has a fairly short development
cycle and only supports one prior major release.
The upgrade process requires not only that all sites be taken
offline, but that some customizations be undone prior to the upgrade
and reinstated afterward. This is done through the GUI and cannot
be scripted, and has to be done individually for all sites supported by
a Drupal instance.
Drupal developers stress heavily the importance of setting up
a test site to test upgrades against your current code.

* Drupal version 6, which just came out of Beta will fix the need to
manually check and keep an eye on all modules for a newer version.
This version of Drupal will tell the administrator as soon as a
newer version of drupal or one of the many modules are released,
thereby making it very simple to know when you should install the
newer version. Installing newer modules (depending on what the
module does) is normally a relatively easy procedure of deleting
the folder for the old module and replacing it with the newer one,
then you may need to do an update on the SQL database by running a
script packaged with drupal. You don't usually need to stop a
module and start it again unless your doing a complete version
update in drupal (5 to 6 for example), which only seems to happen
once a year or so.
* It really doesn't make sense for Drupal to support all of their
prior versions. Version 4 which has been supported for the last
year, while version 5 has been out will probably be dropped soon
as version 6 is now being released. I think a year is plenty of
time to switch over to the newest version (5) of drupal and isn't
a rush by any means.
* As for having a test site, yes you definitely should do that and
test the upgrade before trying it in production. With that said, I
don't think an upgrade has ever failed on me in the past and I've
been working with drupal just a little over a year now. Even if
Drupal isn't supported by the WEG, I don't think they would
upgrade any other CMS without testing it in a non-production
environment first.

Drupal was briefly reviewed by ESS Security:
Sean McCreary wrote, On 12/11/2007 02:26 PM:

A search in the NIST CVE database shows that Drupal has very frequent
problems. In the past 12 months Drupal or Drupal modules have had 45
vulnerabilities registered in the database. Of these, 12 were
classified with a CVSS severity of high, 28 were medium, and only 5
were low. This suggests Drupal will require very frequent upgrades,
perhaps requiring emergency patching as often as once a month. I
think it is reasonable to expect that Drupal will require nearly
constant sysadmin attention, and the system running Drupal should be
quarantined as much as is possible to prevent it from being used to
compromise other systems.

By design, Drupal not only writes to website files but also
to its own program code. The password(s) for accessing the database(s)
are kept in a world-readable (by default during installation) file
that is in the Drupal installation tree. If it must be used, the best
way to run Drupal would be to isolate it on a separate server from
existing WEG servers.
When a Drupal installation is setup for multisites, there is a
default website. Usually this is the first one created. When
the connection searches for a site configuration, it will not
just return the default - it will search in the following pattern,
using the first configuration that it finds. This search behavior
will be an additional consideration for system administrators to
keep in mind.
sites/www.sub.example.com.site3/settings.php
sites/sub.example.com.site3/settings.php
sites/example.com.site3/settings.php
sites/www.sub.example.com/settings.php
sites/sub.example.com/settings.php
sites/example.com/settings.php
sites/default/settings.php
3 - User account information
Account data is kept in the database. Passwords are stored as
an MD5 hash. Since MD5 has vulnerabilities, access to the database and
any backups should be kept as limited as possible.
When creating a user account, the login information is emailed to
the user, who then can login and change the password, but is not forced
to change it. This is not an optional behavior. Two logins are not
allowed to be created with the same email address, although that can
be changed in the database.

* The MD5 hash problem can be corrected with this module
(http://drupal.org/project/phpass) which replaces it with phppass
and removes the MD5 password. This module is currently released
for version 5 and is in development for version 6, which means it
should be something that will be released soon. And in Drupal 7
they should make this a part of the core.

4 - Drupal has its own logging function. It is actually pretty
good as far as logging events, but not so good as for error logging
for troubleshooting purposes. Log levels for PHP and Apache need
to be appropriate for the moment, and web page developers should be
kept aware of PHP warnings or errors, which could proliferate quickly
without being visible to the developer.
5 - Just a usage beef - when a user is creating a page, if you go to a
Help page and come back, the page content is lost.
6 - By default, Drupal cookies are given a life of 2,000,000 seconds.
Three-plus weeks seems excessive. Cookies should probably expire at
the end of the session.

* This can be changed to 0 in the settings.php file which tells it
to expire once the browser is closed.

7 - Logging in is unencrypted. All pages are available via non-https
connections, even after logging in.

* This can be changed by placing the following code into settings.php:
o
*$base_url = 'http://localhost';*
*
*
*if
(!strcasecmp(substr($_SERVER['REQUEST_URI'],0,5),'/user') &&
!isset($_SERVER['HTTPS'])) {*
* header("Location: https://" . $_SERVER['HTTP_HOST'] .
$_SERVER['REQUEST_URI']);*
* exit();*
*}*
*if
(!strcasecmp(substr($_SERVER['REQUEST_URI'],0,5),'/user')) {*
* $protocol = "https";*
*}*
*else {*
* $protocol = "http";*
*}*
*$base_url = $protocol . "://yoursite.domain.com";*
* This code forces an https connection once you go to /user to log
in and is active as long as one is logged in...
8 - Cookies are not typed for encrypted connections - you can login
and send passwords unencrypted.
9 - I can see the potential a race condition to exist in a load
balanced configuration using multiple frontend servers.
10 - Backups of Drupal servers will need to be closely coordinated with
the backup of the database.
10 - If a Drupal website gets trashed, it will not only require a
restoration of the files, but also a coordinated restoration of the
associated database. It has been pointed out that this is not uncommon
for many similar products, but I want to point out that it is not a
feature with more traditional Content Management Systems.