Vista Security, Config, Licensing, Imaging Committee:

Ben, Harjit, Peter, Jonathan, Greg, Dean, Andy G, Phil, E. Mike attending

Imaging:

No real progress on imaging since the last meeting.

We need to look at:

  • Offline image servicing
  • Unattended setup in “Factory Mode” of supplemental software following initial deployment
  • Segregation of WDS servers for Faculty/Staff vs. Student

Security:

Bitlocker

Capability to perform key escrow of TPM and Bitlocker data added to CAMPUS domain. More testing needs to be done. Policy decisions need to be made about:

  1. Mode to implement (PIN vs. USB Key vs. TPM-only systems)
  2. Which systems to implement on (Laptop vs. Desktop, Student vs. Institutionally owned)
  3. How to implement (at deployment time/mandatory vs. after deployment/voluntary).

Editions:

Enterprise

Recommended (Required?) for all Faculty/Staff installs

Business

Recommended (Required?) for all Students systems sold through the depot.

Ultimate

Available though Campus Agreement but not recommended as not manageable though Volume License. Keys will be made available to those who need them, managed through MS licensing web site.

Licensing:

MAK vs. KMS

Both product activations are now available to us for activating Vista Business/Enterprise. Currently only KMS is supported by ETS. We need to establish a method for communicating MAK keys to those who need them, and criteria for when they will be disclosed.

Work-at-Home

Media will be available though the depot in ~January time-frame. This will be retail media, not volume license.

Ultimate Edition

We are entitled to this under Campus Agreement, but it is not a volume-licensed product. Complexity of managing licensing leads us to a recommendation that we not actively promote the use of Ultimate edition on campus, esp. since no systems sold though the depot are media center computers.

Retail/OEM

Need to contact Dell to discuss possibility of re-imaging systems. At present, we have permission to replace OEM-media-based installs with Volume License-media-based installs provided that the system was purchased with an identical Vista SKU (e.g. OEM install of Vista Business may be replaced with VL Vista Business). However, doing this will decrement remaining activations on our MAK, so we will need to broker a deal with MS to provide adequate activations for student systems. Otherwise, we should stick with the OEM-based image and let students re-activate their copy. To pursue this option, we will need more info from Dell (i.e. does Dell use the same media as the basis for all delivered systems? Can an image captured from one Dell system be activated with the key printed on any other Dell system?)

Committee Leadership:

Phil and Greg “volunteer” to co-chair this committee.

ApplicationXtenter Infrastructure Deployment Notes

It seems that I did not take good notes on how to install and configure ApplicationXtender server components. Bah… this made for some fun when rebuilding the test environment. Here goes…

  1. Install Windows Server 2003, Standard Edition, with IIS. 
  2. Bring up to current patch level
  3. Install Oracle Client software…
  4. we used 9.2.0.4 with all patches present on the Prod servers. 
    1. This requires several passes though the Oracle Universal Installer.  First a “runtime” install, then run through again to install “Windows Support Components”, which includes the ODBC drivers that are needed for AppXtender.
    2. Then we need to do two more passes though OUI to install patches, then drop in a few patched DLLs, and finally copy the TNSNames.ORA file from the oracle home on Prod servers to the NETWORKAdmin folder in the Oracle Home on this server.
    3. Update for 2009 – We are now using the 10.2.0.4 database client, but installation is still pretty much the same… you still need the annoying Oracle Universal Installer, you still have to run OUI two to three times.  Additionally, our DBA team has switched from use of the “TNSNames.ORA” file, to “SQLNet.ORA” and “LDAP.ORA”.  Data Source names are now retrieved from an LDAP lookup.  So, ditch the TNSNames file, drop in the new ones.  Also, you must now request a firewall exemption to the database server to make this connection.  Plan a day ahead of time to get access.
  5. Create XS_Global service account, or use existing one. 
    1. Add this account to the local administrators group
    2. Add the additional rights “Act as part of the operating system”, “log on as a service”, and “replace a process level token” rights using the Local Security Policy MMC tool.
  6. Install Legato Licensing Server (if needed… we did not need a new one this time around
  7. Install DiskXtender 2000.  Use existing licensing server if available.  You will need to create service accounts for DX.
    1. Start DX Administrator… you must be a Domain Admin or the local Administrator account.  Members of local Admins have no rights to the DX console!
    2. Extend the local drive that will house your images by going to service->new extended drive.  There are no additional settings that need to be configured here
    3. Under “Service” select “properties”, then “Settings”, and “Partition Map”.
    4. Click “New”, then defined mappings for “DXTEST” (or whatever name you want to give to your DX Instance).  There will ony be one option to choose from under the “Extended Drive” drop-down.
    5. Add another mapping to “OBJECTS”, which will be the subdirectory created by AX in the DX repository.
    6. On the Prod server, we also did the following: Run RegEdit, navigate to:
      “HKLM:SoftwareLegatoDiskXtenderRPCDxCli2”
      Then Modify “TcpIpEndpoint” from 1050 to 6252. This will force DX to use a port that can be accessed from the campus LAN.
  8. Install all AX Binaries… Includes AX Administration tools, ApplicationXtender Administrative installation, WebXtender, Rendering Server, ApplicatonXtender Web Services (IIS Mode).
  9. Open the “System” control panel item.  Go to “advanced”, and under “performance”, click “settings”.  Go to the “Data Execution Prevention” tab, and add an exception for %ProgramFiles%XtenderSolutionsContent ManagementRender ServerWxRender.exe.  This prevents the renderer from crashing in a Server 2003 SP1 environment.
  10. Create shares for “rendering” and “wxsession”.  Both shared need to be accessed Read/Write by the XS Service account.  These allow the rendering service and webXtender service, respectively, to cache files that may need to be accessible to other servers in the AX infrastructure.
  11. Use the “data source selector” tool in the ApplicationXtender Program Group.  Define sources for IMGX and IMGY (test and pre-prod data sources).  You will need to specify the “server name” as “IMGX.world”, and “IMGY.world”, as this is how they are defined in the TNSNames file.  Note that you MUST use the Microsoft OLE DB Provider for Oracle, not the raw Oracle ODBC driver! 
  12. Start XtenderSolutions Administrator (XSAdmin forthwith). 
    1. Login as SYSOP user.
    2. On a new install, you would need to define “Windows Security” as the Security Model in the initial “Environment->Data Sources” window.
    3. Under “Storage->DiskXtender”, we need to have defined:
      Server Name=DXTEST, Connection Type=RPC, DX Network Address=DOCIMGTEST, Network Transport=TCP/IP. Also, on the Prod server, we have defined the “end point” port as 6252.
    4. Under “Storage->Paths”, make sure that any defined paths are valid. It is here that we define the connection to the “rendering” and “wxsession” shares that were created earlier.
    5. Under “WebXtender->Setup”, you must define the service account, and under “Email” you need to specify “smtp.uvm.edu” as the email server, then define a “from” address for the service.
    6. Under “Services->Rendering Server”, you again need to define a service account, then provide the “rendering” share created above as the Cache “location”.
    7. Under “Services->XS Web Services”, define a service account.
  13. Run “User Profile Administrator” in the XtenderSolutions Program Group. We set our users to NOT use the Interactive Client by default. However, using AppGen we have given all users the ability to change this setting.
  14. Run the “Component Setup Wizard” in the XtenderSolutions Program Group. Run through the wizard for each component in the infrastructure (XS Web, WebXtender, Rendering Server).
  15. Updated for 2009 – IIS Tuning:
    1. In IIS Admin, get properties on the default web site, access the “Directory Security” tab, and install a server certificate.
    2. Click “Edit” to require SSL for the site
    3. Go to the “Custom Errors” tab, and add our standard JavaScript redirect html file in place of the 403.4 error page… this will force users over to the SSL version of the site using a javascript redirect, instead of displaying an ugly error page.
    4. On the “Home Directory” tab, add a permanent redirect from the base web site URL to the “/AppXender” subdirectory
    5. Get properties on the /AppXtender subdirectory.  In the “Documents” tab, add “Default.aspx” as a default content page.  Failure to do so will result in an “403.14” error page.

Preparing for the Sharepoint v3 upgrade

The following steps may be accomplished before production service outage begins:

  • Install OS Services in support of Sharepoint 
  • Install .NET 3.0 framework
    • ensure that ASP.NET is installed on IIS server, make sure that ASP.NET 2.0 is activated:
      (run C:WINDOWSMicrosoft.NETFrameworkv2.0.50727aspnet_regiis -i
  • Install WSSv3 (but cancel the configuration wizard)
  • Perform admin site config:
    • Configure to use NTLM authentication, NOT KERBEROS!
    • set incoming and outgoing email settings.
      • Requires SMTP server running on WSS server, mail domain set to be the same as that of the Sharepoint server config.
  • configure Search Services
  • define quota templates (create 5 and 10 Gb quotas)(cannot assign to application yet, but can create)

These procedures to be completed duing the announced service window:

  • Run the “prescan” tool from the “
    C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN>” directory on the wssv3 server on the production site
  • Set the production server DB to read-only
  • Back up the DB
  • Restore the DB to WinDB, set to SQL v9 compatibility, restore permissions to the DB for the new production server (wss content app pool and wss access accounts)
  • Create new “Web Application”:
    • Map search services to the application
    • Add SSL redirect to the IIS site that is created (replace the 403.4 error page with a custom Java Script redirect
  • Replace new content DB with copied content DB on WinDB.  Use command-line “STSADM” tool as Web GUI will not work here.
  • Extend the new application to allow for Extranet config:
    • Create an additional IIS web site which listens on an alternative IP address/port
    • In Application Management, click “Create of extend web application”
    • Click “Extend an existing web application”
    • Choose to use an existing IIS site, select the site you just created, and select this app as being in the “Extranet” zone.
    • return to IIS management, make sure the IIS site is configured to listen on the appropriate IP and ports, ensure SSL is enabled, and replace the 403.4 error page on this site, too.
      • Make sure that BOTH IIS sites have SSL bound to a specific IP address, otherwise port conflicts will occur!
    • Enter “Alternative Access Mappings” from the “Operations” page. Add a new “internal URL” for the extranet site.
    • Enter “Authentication Providers” from “Application Management”. For the “Extranet” zone, Specify “Windows Authentication”, “enable anonymous”, “basic authentication”… may also need to disable “client integration” features.
  • Restore custom settings to the site:
    • web application general settings – set Time Zone, default quota template, increase max upload size, activate Blog API auth, turn off “send password”.
    • Self-service site creation – activate, require secondary contact
    • Site use confirmation and deletion (set to 365, monthly, 3 notifications)
    • others?
    • Do “alternative access mappings” in Operations->Global Configuration. Use FQDN of service!
      • Add FQDN for extranet access as well, going to extranet zone.
  • Configure Search (only necessary if unable to map to an existing search service, above):
    • create service account
    • run stsadm -o spsearch -action attachcontentdatabase -databaseserver WINDB -databasename [DBname] -searchserver WSS3TEST
    • run stsadm -o spsearch -action start -farmserviceaccount campussa_wss3test_search -farm
      servicepassword [password] -databaseserver WINDB -databasename [searchDB]
    • install additional iFilters (?)
  • Install MindManager extension
  • Perform Extranet config… have not modeled this yet so steps TBD.
  • Fix self-service site creation link on home page, if necessary.
  • Add announcements to sites/ad/
  • Take down old Sharepoint server
  • Appropriate production IP addresses
  • Install site SSL cert from production site.
  • Testing:
    • Open several sites just to see if general functionality is present
    • Test URL redirection:
    • Test incoming e-mail
      • Activate on a site library and discussion list, attempt to post with e-mail
    • Test workflow
      • Create a workflow, assign to library, make mods which would trigger workflow.
    • Test recycle bin operations.
    • Test new site creation
    • Test backup AND MORE IMPORTANTLY restore of a single site