Recently we had corruption of a number of our Virtual Machines (caused by a fault in the firmware of our “enterprise” storage system from a Nameless Mainstream Vendor, which was triggered by unexpected filesystem behavior from an Evil Mainstream Company’s virtualization platform).  This event forced us to exercise our system disaster recovery tools, (also from a Nameless Evil Mainstream Company) and brought us to the subsequent discovery that some backup products just don’t do DR.  There is much that could be said about that, but I will leave it there.

Anyway, we thought we would have a look at Microsoft DPM 2007 SP1 to see if the DR story there is any better.

Here are some sticking points I have hit while evaluating the product:

• Server Recovery Tool (SRT) – This is the Bare Metal Recovery component of DPM.  As it turns out, it only can protect Server 2003 and XP systems.  Server 2000 is a no go (no tears here…), as are Server 2008 and Server 2008 R2 (aargh!).  SRT is pretty easy to setup and configure, but keep in mind that it must run on a Server 2003 OS (not Server 2008!).
• DPM Reporting Services – The DPM installer creates a IIS instance on your machine, and configures/installs SQL 2005 with Reporting Services.  Very nice!  Unfortunately, the installer misses one critical IIS setting when installed on Server 2008:
  http://scdpm.blogspot.com/2009/07/reporting-does-not-work-with-dpm-2007.html
  You need edit the feature permissions on the the “HTTP Handler Mappings” feature on the Reporting Services IIS site to allow “Script” access (not script execution, just script access).  After that, you should be able to run reports from the DPM console.
• Updates – In addition to SP1, there are numerous hotfix rollup packages available, of which you should take advantage. 

• Here the the most current DPM update pack, as of the time of this writing:
  http://www.microsoft.com/downloads/details.aspx?familyid=14E1A04B-2323-4344-B737-A3194B9AB3ED&displaylang=en
  In my case, I need this to address errors in the WSSCmdletsWrapper that crop up when attempting to create a protection group for Windows SharePoint Services.  Keep in mind that you need to update the server and your DPM Agents.
• You may also need VSS updates:
  http://support.microsoft.com/kb/940349
  It appears that VSS updates are available only for Server 2003.  I guess Server 2008 is perfect and does not need VSS update

• You must configure your WSS VSS Agent to run as an account that has both local Administrator rights on the SharePoint WFE, and Farm Administrator rights.  The writer must be configured after installing the DPM agent and before attempting backup.  Use “ConfigureSharePoint.exe” in the DPM bin directory to make these changes.
• You also can configure backup of MOSS Search, which is accomplished using a different switch to the “ConfigureSharePoint.exe” tool.
• The VSS updates mentioned above are required before backing up a WSS farm.
• Server 2008 DR – Documentation on this really bites.  I sent the following feedback to the DPM whitepaper team for their document on Server 2008 Bare Metal recovery (How to do Bare Metal Recovery of WS08 with DPM 2007 SP1):

There are a few points in the white paper that require some clarification as they will confuse most readers.  I also have a few questions about the reasoning behind some of the steps in the document.

1. In the section "Before you create the protection group" under "Configuring Backups for BMR" it is unclear on which system you should be performing these steps.  A seasoned DPM admin will be able to figure out that these steps need to be performed on every system which will be backed up, but a newbie will not know this.  The instructions should be more explicit. 
2. The instructions have us create a share on the local server rather than simply backing up the WSB image to a named volume.  Why?  It would seem that backing up to a local share adds unnecessary complexity to this operation.  Using a local volume will be simpler and more secure. 
3. Similarly, in the recovery instructions we are told to restore the system image to a local share.  Why?  In a bare metal recovery scenario, there is no local share to recover to!  The server referred to as "%computername%" in the recovery will likely be offline, and thus not available as a recovery target.
4. In step 3 of "Configuring Backups…" we instructed to add the PreBackupScript commands to the "PSDataSourceConfig.xml" file, but we are not told within which XML tags to insert the code.  I was unable to make Pre-backup scripts run when following these instructions.  Instead, I placed the code snippet into "ScriptConfig.xml" (where other documentation suggests that this code actually belongs), and my backup jobs then started to run.
5. There is no guidance here about the frequency with which BMR sets should be created.  Unfortunately, I can find very little in the way of best-practices on this subject (Server 2008 disaster recovery, as a general topic).  It seems that weekly (or perhaps even monthly) BME sets followed by daily "standard" DPM backups would be adequate to protect most operating systems, but it would be nice to have some verification of this.  Can you point me to any additional documentation on this subject.

• Server 2008 DR needs some improvement, to be blunt about it.  The team promises better BMR integration under DPM 2010, but details are not yet available.

Initial architecture will be something like this:

• Host: SharePoint2
  • Roles:  Web front end, Search Server query and crawl, ECTS ADAM Instance
• Host: SharePoint3
  • Roles:  Web front end, Search Server query and index, ECTS ADAM Instance
• Hosts: WinDB1 and WinDB2
  • Roles:  Back-end SQL Database failover cluster
• F5 Big-IP Local Traffic Manager (hardware load balancer)

Once initial rollout is complete, we likely will want to add:

• Host: SharePoint3
  • Roles: Dedicated Search Server Index and crawl engine.
• Hosts: WinDB1 and WinDB2
  • Reconfigured in a SQL mirrored configuration

Here is an outline of the SharePoint2/3 build procedure:

1. Install Server 2008 x64 Standard OS
   1. Activate Roles:  IIS (with ASP.NET support), AD Lightweight Directory Services (AKA AD LDS, AKA ADAM).
   2. Activate Features:  .Net Framework 3.0, PowerShell
2. Install Search Server Express x64 bits:
   1. Perform “complete” install (Search Server will not install a SQL 2005 instance, as is the case with WSS installer).  Under “file location”, specify “E:\Office\12.0\Data” as the index storage location.
   2. Skip running of the Configuration Wizard after install.
3. Install SharePoint Administration Kit v2.0
   1. Exclude Profile replicator component as it will not work on WSS
4. Clone the server as many times as deemed necessary. (At present, make one clone!).  Any cloned systems must be sysprep-ed before joining the domain.  Once preped, join the computers, configure networking.
5. If planning to add this server to a load balanced cluster, install NLB feature:
   • from “administrator” cmd shell, run “ocsetup NetworkLoadBalancingFullServer”
   • Don’t join to a production NLB cluster until SharePoint configuration is complete!
6. Replicate AD LDS (ADAM) instance to new machine, if required.
   1. In Server Manager, Click on “AD Lightweight Directory Services” Role,
   2. Click “AD LDS Setup Wizard”
      1. Select “A replica of an existing instance”
      2. Name the instance “ECTSInstance”
      3. Accept standard LDAP ports
      4. specify a partnerpoint server to replicate from, use standard LDAP ports.
      5. Select the “OU=ects,…” partition set for replication (this should be the only partition!)
      6. Select secondary (non-system) volume as target for AD LDS data… generally this will be “E:\Microsoft ADAM\ECTSInstance\data”
      7. Specify domain service account to run the AD LDS instance.
      8. Add “domain admins” to the AD LDS Administrators list.  Finish the wizard.
   3. Run the campus…bat file located in e:\Microsoft ADAM\ECTSInstance\data\.  This will register the Kerberos Service Principal Names required for LDP replication mutual authentication.
   4. Open the “Local Security Policy” Admin tool.  Add the domain service account to the “generate security audits” User Rights Assignment branch.
   5. Open the AD Users and Computers tool, locate the computer object on which you installed the Instance.  Give the LDS service account “create all child objects” to the computer object.
   6. Add the cluster load balanced SSL cert into the Personal certificate store of the ECTSInstance service account.
      1. Request wildcard certificate using the procedure outlined here:
         http://erlend.oftedal.no/blog/?blogid=7
         (We use the web interface for requesting a certificate, make user we use the RSA SChannel crypto provider to generate the request, use the “SHA-1” hash, use PKCS10 format, and use the “UVM – Web Server” request template.  For load-balanced LDAP servers, we must request a wildcard certificate (*.uvm.edu)
         NOTE: This step will not have to be repeated again until the current cert expires.  To add another AD LDS server, export the cert from a current server, import into the new server
      2. Export the request cert to file selecting “export all extended attributes” and “export private key” options.
      3. Import the cert into the “Personal” branch of the service account’s certificate store on the target server.  Make sure that you import “all extended attributes”, and the private key.  Do not select the use of advanced encryption password.
      4. Restart AD LDS and test SSL connections.
      5. If all is not working (as is the case with one of my two servers), here is where we get into undocumented territory.  Here are some helpful resources for debugging:
         1. I set SChannel diag logging to verbose :
            • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel
              REG_DWORD EventLogging, value 0×7
            • Restart ECTSInstance, look for “SChannel” entries in the server “application” even logs.  These logs will tell you which certificate the system attempted to use, and why access failed.
         2. You may need to add the wildcard cert to the Local Computer Certificate Store as well… run MMC, add the “Certificates” snap-in for “Service Account”, using the “ECTS Instance” service.  Navigate to the “Personal” branch, run an import action, import the wildcard with all extended attributes and the private key.
         3. Now locate the physical copy of this cert in c:\programdata\microsoft\crypto\RSA\MachineKeys (it will be the file with the most recently modified time stamp).  Add “read/execute” permissions to this file for the AD LDS service account, then restart the LDS instance.
   7. Force mutual authentication for replication traffic:
      1. Run ADSI Edit
      2. “Connect to”, enter the AD LDS server name in the Computer field, select the “Configration” well-known naming context.  As documented in http://technet.microsoft.com/en-us/library/cc794841.aspx, get “properties” on the “CN=Configuration…” partition, and change the value of “msDSReplAuthenticationMode” to “2”.
   8. Set local password policy – this controls password policy of AD LDS accounts:
      1. Add the Sharepoint server computer account to the “ETS – SharePoint Password Policy” GP Object.  After running “gpupdate /target:computer /force”, verify the settings by doing the following:
         1. Open Local Security Policy control panel
         2. Expand “Account Policies”->”Password Policy”
         3. Settings applied should follow the 24/365/0/8/Disabled/Disabled format.  (we may want to revisit this policy later).
7. Run the SharePoint Products and Technologies Configuration Wizard:
   1. Connect to an existing Farm
   2. Enter “WINBD” as the database server.  The wizard will correctly select “SharePoint_FarmConfig” as the configuration database.  The correct service account username will be provided… you need to enter the password.
   3. Click “Advanced Settings”, specify that you which the server to host the Central Admnistration site.
      1. If setup fails with the error:
         "SharePoint Configuration Wizard failed with an exception "Error during encryption or decryption. System error code 997"
         A solution can be found here:
         http://blogs.msdn.com/priyo/archive/2007/08/11/add-new-sharepoint-server-to-existing-server-farm-an-unhandled-exception-occurred-in-the-user-interface-exception-information-unable-to-connect-to-the-remote-server.aspx
         Essentially we just run “stsadm –o updatefarmcredentials –userlogin “domain\service_acount” –password <thePassword>” on the first SharePoint server, then re-run the wizard.
   4. Update the “Central Admin” shortcut to point to the local Central Admin site by doing the following registry hack:
      http://blogs.technet.com/wbaer/archive/2007/08/30/sharepoint-3-0-central-administration-url-on-multiple-web-front-end-servers.aspx
      Essentially, edit the key:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS
      Then locate CentralAdministrationURL and change it to point to the local server.
8. Configure Search Service:
   1. When Search is run in an environment where SharePoint services are accessed from a FQDN which is different from the physical host name (i.e. our environment, or any other environment with load balancers), you will need to work around the “loopback security check” feature of Windows.  Failing to do so will result in “access denied” errors in the crawl logs.  My thanks to Shawn Feldman for discovering this:
      http://blogs.msdn.com/fledman/archive/2008/09/18/access-denied-with-windows-server-2008-and-moss-when-crawling.aspx
      The relevant work-around is documented here (see “Method 2”):
      http://support.microsoft.com/kb/896861
      We simply need to add the public FQDN of our SharePoint server to:
      Key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
      Value: REG_MULTI_SZ, sharepoint.uvm.edu
      And then restart the IISAdmin service.
   2. Open the search admin page from SharePoint Central Administration:
      1. Access Crawling –> Content Sources
         1. Click the “Local Office SharePoint Server sites” default source.
         2. Define a crawling schedule for the SharePoint application
         3. Click “new content source” to add any additional content sources that are desired (i.e. our production file servers).
         4. Define additional crawl schedules for these new content sources.
   3. Add Search Center to our SharePoint landing page:
9. Install Infrastructure Update for WSS3 x64:
   1. Initiate the update on the first node in the cluster. 
   2. When prompted, start the install on the second cluster node.
   3. When the configuration wizard completes on the second node, go back to the first and allow configuration to complete.
10. Install Infrastructure Update for Search Server x64:
    1. Initiate the update on the first node in the cluster. 
    2. When prompted, start the install on the second cluster node.
    3. When the configuration wizard completes on the second node, go back to the first and allow configuration to complete.
11. Clean up IIS settings for the newly created Web Sites – configure binding, authentication and SSL:
    1. SSL Cert Installation: 
       Install SSL certs into “Personal” Store of the Computer account using the “Certificates” MMC snapin.
    2. Binding: 
       Open the IIS Manager MMC snapin.  On each site, right-click and select “edit bindings”:
       1. For site “SharePoint – 443” (which represent the traditional “sharepoint.uvm.edu” URL), bind https and http protocols to port 80 and port 443, using the IP address for “sharepoint.uvm.edu” (132.198.102.12).  When binding SSL, select the appropriate cert from the “SSL Certificate” drop down menu.
       2. For “SharePoint – Internet” (which represents SharePointLite), bind https and http, ports 443 and 80, to “sharepointlite.uvm.edu”, IP 132.198.102.36.  Again, select the correct SSL cert for this site.
       3. For “SharePoint – Extranet” (which represents PartnerPoint), bing https and http, ports 443 and 80, to “partnerpoint.uvm.edu”, IP 132.198.102.49, selecting the matching SSL cert once again.
    3. SSL Configuration:  (Note that these procedures are only accurate when using Windows-native load balancers… when we transition to f5 load balancing, it will not be necessary to return custom errors from IIS as the f5 will handle HTTP-to-HTTPS redirections.)
       1. In IIS Manager, open the “features view” for each site.
       2. Double-click “SSL Settings”
       3. Check “Require SSL”, leaving the default “ignore Client certificates” setting.
       4. Now double-click the “Error Pages” item for the server root.  Add a custom error for 403.4 (SSL required), pointing to our custom “redirect.html” javascript file.  We will need to have copied this file into “c:\inetpub\custerr\en-US\” before completing this step
       5. Now find the applicationHost.config file for the IIS server.  This should be located in “C:\Windows\system32\inetsrv\config”.  Locate the section for each site that serves SharePoint content (i.e. <location path=”SharePoint – 443”>), then locate the <httpErrors> tag under <system.webServer>.  In the httpErrors tag, change the value for “existingResponse” from “PassThrough” to “Replace” (response “Auto” also seems to work, but may produce inconsistent results).  This will prevent ASP.NET from replacing the 403.4 error response from the IIS server.  I am much indebted to this forum thread for this breakthrough:
          http://forums.iis.net/t/1113734.aspx
          Also helpful was the new “failed request tracing” module in IIS7:
          http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis7/
          More information on the meaning of the various existingResponse values can be found here:
          http://blogs.iis.net/ksingla/archive/2008/02/18/what-to-expect-from-iis7-custom-error-module.aspx
12. Install the MS FilterPack 1.0 (Search Server can already index most Office 2007 documents, but this adds ability to index inside of One Note files and ZIP archives):
    1. Follow instructions at:
       http://support.microsoft.com/?id=946336
13. Install Adobe iFilter, with 64-bit “thunking” DCOM service:
    • http://labs.adobe.com/wiki/index.php/PDF_iFilter_8_-_64-bit_Support
    • http://workerthread.wordpress.com/2008/07/18/adobe-reader-9-available-works-fine-with-sharepoint/
    • http://servergrrl.blogspot.com/2008/01/and-now-for-something-completely.html
    • TEST IT… Internet chatter suggests that this config is less than reliable.
14. Install MindManager extensions.
    1. DEPRECATED – We will discontinue this extension with the new upgrade as it does not work with MM v7 or v8
15. Install ECTS components on each web front end server.
    • Having problems with installation script… what if we try the ECTS update available though CodePlex???
      1. If using updated ECTS files, it will be necessary to update the PartnerAdmin and PartnerConfig pages, as the self-service Site Collection Manager.  The existing pages will not work because the GUIDs on the Web Parts have changed. 
      2. The ects_setup_sharepoint.vbs script still fails using the updated code… Since the codeplex team has not documented their changes, I think we will skip this option.
    • Troubleshooting issues:
      1. The ects_setup_sharepoint.vbs script succeeds in installing the ECTS solution, but fails when activating site features.  I suspect that “cscript” on Server 2008 is not processing return codes from stsadm.exe correctly, and this is reporting failure to install features (I am not positive about the reason for the script failure, although it certainly is not a result of stsadm.exe being broken. 
         I was able to work around this problem by opening the ects_setup_sharepoint.vbs file in a text editor, searching for the error string that was sent to the console when the script failed, then running all of the operations in the script manually from that point forward.  Fortunately, all of the stsadm commands in the script are successful when run from the command line.
      2. ECTS is not compatible with MS Load Balancing out of the box.  I switched to a F5 load balancer before working through the problem.  It is possible that the problem I was having could have been fixed with the same “loopback security check” that caused problems during our F5 configuration
         http://support.microsoft.com/kb/896861
         In fact, we may have had the problem even with the f5 in place, but I would not know because I applied the loopback fix before implementing the F5.
         The error codes suggest that a login failure is occurring between the IIS application and the AD LDS LDAP instance.  When I try to connect to the load-balanced LDAP DNS name using the “LDP.exe” LDAP client, I also get an authentication error.  However, when I connect to the local server address, authentication works. 
      3. As was the case when I first installed ECTS, the web.config files required a bit of hand-tuning to get services working correctly:
         http://www.uvm.edu/~jgm/wordpress/?p=112
         Once again, I had to modify the “ADAMConnectionString” in the web.config of each IIS site to reflect the actual DNS name of the load-balanced AD LDS servers.  I had installed ECTS using a different name initially, and the ECTS un-installation script did not clear out these values.
      4. I did find it necessary to deactivate all ECTS site collection features, re-activate them, then perform an IIS reset before my existing ECTS management pages would work again.  This seems pretty par for the course when removing and re-installing SharePoint solutions.
16. Install Globally-deployable solutions from the “fab 40” application template.  If you deploy a web front end into an existing farm, the files required by these features will get transferred automatically.  However, when building a new farm, we need to install them manually.  Currently required “server admin” templates are:
    • ApplicationTemplateCore
    • ChangeRequest
    • ContactsManagement
    • DocumentLibraryReview
    • EventPlanning
    • HelpDesk
    • InventoryTracking
    • ITTeamWorkspace
    • Knowledgebase
    • LendingLibrary
    • PhysicalAssetTracking
    • ProjectTrackingWorkspace
    • RoomEquipmentReservations
    • Procedure:
      • stsadm -o addsolution -filename <file_path>\<template_name>.wsp
      • stsadm -o deploysolution -name <template_name>.wsp –allowgacdeployment
17. Install radEditor:
    1. Install ASP.NET Ajax for .NET 2.0, version 1.0
    2. Follow the Ajax configuration for SharePoint configuration guide found here:
        http://sharepoint.microsoft.com/blogs/mike/Lists/Posts/Post.aspx?ID=3
    3. Install radEditor using the included instructions.
    4. Copy radEditor configuration files from an existing production server to the new server:
       1. In the directory:
          ”C:\Program Files\Common Files\Microsoft Shared\web server extensions\wpresources\RadEditorSharePoint\[versionString]\RadControls\Editor”
          Backup the existing ListConfigFile.xml, ConfigFile.xml, ListToolsFile.xml, and ToolsFile.xml files.  Replace with versions customized for UVM.  Note that the MOSS LinkManager tool does not work in WSS.  Also note that when editing list content that does not support “Enhanced Content”, the first toolbar in the ListToolsFile.xml will be removed… in past versions, the toolbar named “enhancedTools” was removed.
       2. Copy the files ListConfigFile.xml, ConfigFile.xml, ListToolsFile.xml, and ToolsFile.xml to all other nodes in the cluster.
       3. perform an IISRESET.
       4. Update ONET.xml files in the “12” hive to activate the radEditor feature by default in all new sites (see ONET.xml template files on the prod web front end for examples).
          NOTE that the “RadEditor for non-IE browsers” and “RadEditor for IE” features have been collapsed into one unified feature.  Update the ONET.XML files accordingly!  (note that the feature ID for the main RadEditor List editor has not changed… only it’s name is different.  We did not have to insert a new default feature ID, but we did need to remove the “RadEditor for IE” feature because it is no longer present in RadEditor MOSS.)
       5. Run:
          stsadm –o uninstallfeature –name RadEditorFeatureRichHtml.
          This “Web Content Management” feature is not supported in WSS, so we may as well remove it to avoid confusion.
       6. Deactivate and then re-activate the radEditor features on at least one existing site, and test functionality.
18. Install “Smiling Goat” Feed Reader (RSS/ATOM subscriber web part)
    1. This will require Feed Reader users to update their web parts!
19. Install SharePoint Training Kit:
20. Tune web application settings to match production server:
    1. Set upload limits for files (also need to set IIS “maxAllowedContentLength” in each web.config to be longer than the SharePoint upload limit.  See http://support.microsoft.com/kb/944981/en-us for details.)
    2. Set time zone
    3. Set allowed/disallowed MIME types
    4. Set quota templates for new sites
    5. Config incoming/outgoing email settings
    6. Config site expiration/auto-deletion.
    7. Edit the footer of the “welcome” email message starting at line 5219 of “core.en-US.resx” in the 12-hive “resources” folder.  Replicate on all web front ends in the farm.
21. Configure f5 load balancers:
22. TEST TEST TEST:
    1. Test each feature on both web front ends by alternately disabling the nodes in the load balancer configuration.
    2. Test again with both nodes enabled… watch for authentication and session persistence issues.
    3. Test all features in each access mapping – SP, SPLite, and Partner… web.config file variations could cause problems!
23. Consider Deployment of “Group Board 2007” and “Sample Master Pages”:
    • http://www.microsoft.com/sharepoint/templates.mspx

http://www.codeplex.com/governance/Release/ProjectReleases.aspx?ReleaseId=4622

Unfortunately, this product just is not going to work for us.  It is possible that we could wrangle it into shape with enough time, and an ability/desire to check the code out of codeplex and patch it up.  However, I just can’t bring myself to deal with it.  Here are some problems that I encountered:

1. The utility has not been tested or developed to work on the Server 2008 platform.  The directions are written with Server 2003 as a reference platform, and tell you do do things like “create a virtual directory” when what they really want you to do is to create an application in your IIS App Pool.  I could live with this but…
2. The tool does not work on Server 2003 either, at least, not when using WSS 3.0 Service Pack 2.  The web.config file in the LCMWeb directory references an assembly in the GAC named “Microsoft.Internal.MIME”, with the version 8.0.0.0.  Guess what?  That assembly was upgraded with Service Pack to to version 8.0.681.0.  But even after updating the web.config file to the new version, I still get errors when attempting to load the LCMWebConfig.aspx page.  humph.

Essentially, this tool is not supported, and ,to make matters worse, it is not being maintained.  I really would hate to spend time beating it into shape only to have the damn thing break when the next service pack or release of WSS comes out.

Attempts to delete a site result in “Access Denied” error messages in the site delete log files.  No corresponding events found in the Security Event logs, nor are we able to detect any “ACCESS DENIED” messages using procmon.exe.  What’s up? 

Well, in this thread:
http://governance.codeplex.com/Thread/View.aspx?ThreadId=11781 
one of the project authors suggests that the utility requires additional rights beyond the “least-priviledge” baseline, specifically, the account running your SharePoint WFE applicaiton pool needs to be a “Farm Administrator”, and it needs “Full Control” over the web application.

Much as I did not like this suggestion, I decided to give it a try in the test environment, but it fails anyway.  Further investigation reveals that the sharepoint WFE service account is not actaully capable of performing site backups.  If you log in as the service account, you cannot run any “stsadm” commands at all… every command results in “ACCESS DENIED”.

It turns out that stsadm.exe will not run without local administrator privs.  It also would seem (although I cannot prove it) that the Site Delete Capture utility is using stsadm functions to generate its snapshots.  Since I will not be giving our SharePoint WFE app pool local admin rights, I guess I cannot use this utility.  On to testing the Site Lifecycle Manager instead…

Possibly of most use would be:
http://www.codeplex.com/governance/Release/ProjectReleases.aspx?ReleaseId=14351
A utility to automatically backup sites upon deletion actions.

And:
http://www.codeplex.com/governance/Release/ProjectReleases.aspx?ReleaseId=4622
Site Lifecycle Management – a potential replacement for the hated “Site Expiration” process we have in place at present.

With support for 5.30 expiring today, I think it high time we got our infrastructure up to date up to the most current version that is supported for use with SunGard Banner.

1. Uninstall all previously existing AX components.  Purge any residual files from the IIS  publishing directories, “Program Files”, “Application Data”, and the registry.
2. Set security for the global impersonation account according to the table on page 210 of the “concepts and planning guide”.
   1. Note that the account does not have to be a local administrator!
   2. However, the security accounts will have to have privileges to the resources accessed by the services (i.e. NTFS filesystems rights, shared folder access).
   3. Rendering Service -
      1. When granting rights to the DX data store, plan ahead.  Permissions could take a long time to apply.
      2. Requires Local Security Policy “Replace a Process Level Token” and “Adjust memory quotas for a process” rights.  Also, the “Allow service to interact with the desktop” box must be deselected in the “Log On” tab of the Rendering service properties.
   4. WebAccess.NET Services -
      1. Global Account needs only “Log on as a service” Local Security Policy assignment.  You can clear out all “legacy” security permissions as they are not needed for WebAccess!
3. Install AX Desktop, installing all administration tools:
   1. msiexec /i “ApplicationXtender Desktop.msi” /qb ADDLOCAL=DocumentManager,AppGen,ConfigurationTools,ManagementTools
4. Install the new License Server and install license file:
   1. Install the “ApplicationXtender License Server.msi” (FlexNet License Manager)
      1. Drop the .LIC license file into C:\Program Files\XtenderSolutions\Content Management\License Server
      2. Configure the Login identity of the “ApplicationXtender License Client Components” COM+ application to use the global impersonation account.  This component must be shut down to be reconfigured.  Details in EMC PowerLink solution esg92864.
      3. Restart the “ApplicationXtender License Service” Service.
   2. Install the “EMC License Server” (Proprietary License Server, to support DiskXtender)
      1. Install all current patches to the service
      2. Run the “License Server Administrator” GUI.
      3. Go to “Tools”, then “New License Wizard” to install the DiskXtender License.
5. Install DiskXtender
   1. Install DiskXtender patches, in sequence
      1. When prompted for the DX service account, you must provide an account that has local “administrator” rights, and the ability to “log on as a service”.
   2. Verify and/or re-establish RPC partition maps – See the “Core Components” guide for instructions.
   3. Consider switching to DCOM security model, which will require modifying the “AE_PATHS” table in each data source db.   See page 160 of the “Desktop Install Guide” for details.
      1. This is not actually practical to do since it will break AX Desktop on any system that is not joined to the CAMPUS domain (and why would they not be joined, I wonder?)
6. Launch AX Admin
   1. See “ApplicationXtender Desktop Installation Guide” for details
   2. Log in as SYSOP and perform the database upgrade, if prompted.
   3. Verify global settings:
      1. Add license server configuration: see “Core Components” guide for details.
      2. Web Access .NET must use Global credentials since we are using and Oracle database with Oracle security.
   4. Save the configuration and exit
7. Launch AppGen, and verify functionality.
   1. Connect to each defined data source, one at a time.
   2. Perform database upgrades if prompted (this should be safe, but can take several minutes to complete).
8. Set IIS web site root to use ASP.NET 2.0.
9. Install AX Web Services, making sure to install the required “Utility Services” component.  “AX Web Services” and “Workflow” components are optional.
   1. See “AppXtender Core Components Admin Guide” for installation and config details.
   2. Choose IIS installation option, and install into “Default Web Site” (which should be the only site present)
   3. Ensure that “Default.aspx” is listed as an accepted default page for the “AppXtender” IIS web application.
10. Install AX Web Access .NET
11. Install AX Rending Server
12. Run the Component Setup Wizard for all installed components
13. Outside of my control:
    1. BannerXtender updates need to be applied to production Banner systems.
    2. DocSend and ECopy stations need to be upgraded to 5.40 AX Desktop releases
    3. DocAccel server needs 5.40 AX Desktop upgrade
    4. All AX desktop clients need updates, too.
    5. Anyone using WX WebAccess.NET ActiveX controls will need to upgrade these components.
14. Test Test Test!

Here are a few ideas I have been considering for addition to our MDT Workbench:

• Use the MDT Wizard Editor to add a page for whole-system backup.  This functionality has been requested by our College of Medicine IT Staff.
• Implement the “Roles Wizard” solution to allow Distributed IT staff the ability to select MSD database roles for their system.
  • This will require that I farm out data writer rights to the MSD database, too.
• Move all online versions of the MDT Distribution Points to our NetApp network storage and activate de-duplication features… this should keep the whole bloated thing much more trim.
• Create Model Aliases for Apple computers.  This will be helpful as we gear up for BootCamp support.
• Finish my own disk paritioning script to add support for BootCamp, and to preserve OEM utility partitions.
• Integrate all current Dell Driver CABs… figure out if there are notifications available for these.
• Move “sensitive” application installers into a single central distribution share and secure them.  Do not replicate these installers to secondary distribution points.
• Implement “media” based deployment points to allow high-speed deployment from low-speed networks.

A few tidbits so far:

• There appears to be a missing manual, available at various places on the Internet, but not from Microsoft.  Perhaps it came with the MED-V beta?  Anyway, it has some good step-by-step configuration info for IIS that is not present in the official manual.  Get it here:
  http://www.mvug.co.uk/media/p/120.aspx
• When setting up an HTTP distribution server for MED-V, make sure the following role services get installed:
  • BITS Server Extensions (added as a general feature after IIS is installed)
  • Windows Authentication
  • Basic Authentication
  • Client Certificate Mapping Authentication
• You will need to grant read/write access to the image upload directory on the IIS server… kind of a “duh” note; however, you may want to add the permissions from the IIS console rather than from explorer, as doing so avoids issues with web.config and BITS transaction file permissions.
• Before you download a MED-V image to a MED-V client, you will need to add the two following MIME types to the IIS server:
  • .index – application/octet-stream
  • .ckm – application/octet-stream
• Reporting Database configuration:
  • Documentation suggests but does not specifically state that when configuring MED-V to use a remote SQL server for the reporting database, you should need to use SQL Authentication. If you attempt to use Windows Integrated security, you will see that the Med-V service attempts to connect to the new database as an “anonymous user” (which, of course, fails).
  • The documentation tells you to provide the SQL Server “SA” login and password to the MED-V database configuration tool.  This, if course, is not necessary.  You can and should create a separate SQL login for MED-V.  This login will need to have “dbcreator” rights at the time you create the database, but this role can be revoked as soon as the database has been created.
  • Your database connection string should resemble the following example:
    Data Source=DBSERVER1\Instance1;Initial Catalog=MEDVReports;uid=medvReportUser;password=G1bb3r1$hP@ssw0rd
• XP Image Configuration:
  • When configuring your XP image for sysprep and domain join, you must create an sysprep.inf configuration that will run mini-sup in fully unatteded mode.  You file must contain the following entries in addition to your preferred local settings:

  [Unattended]
  InstallFilesPath=C:\i386
  OemSkipEula=Yes

  [GuiUnattended]
  OEMSkipRegional=1
  OEMSkipWelcome=1
  AutoLogon=Yes
  AdminPassword=”insertYourPasswordHere”
  EncryptedAdminPassword=NO
  AutoLogonCount=5

  [Identification]
  JoinWorkgroup=UVM

  [Networking]
  InstallDefaultComponents=Yes

  [UserData]
  ProductKey=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
  FullName=”User Full Name”
  OrgName=”Your Organization Name”
  ComputerName=*

  • You also must configure the automatic administrator logon option for at least as many times as are required to perform your planned computer rename and domain join operations (whcihc would be two reboots, but you might want to pad it a bit to be safe).  Keep in mind that the MED-V client will not be able to hook into the guest GINA using your MED-V login creds until the workstation has been joined to the domain.

Run Screaming

Okay, that may be a bit damning… here is a qualifier.  If you have no SLA with your customers, don’t mind lots of downtime, love C# programming, and otherwise find SharePoint troubleshooting highly amusing, then ECTS is the solution for you.  Otherwise, try something less painful.

The main discovery that pushes me to make this recommendation is that the ECTS solution is not supported by Microsoft.  The head of the MS Solutions Accelerator group once told me that all Solutinos Accelerators for currently supported MS products are supported by Microsoft.  This is not actually the case.  Always read the fine print for your Solutions Accelerators.  In the case of ECTS, we find the following in the ECTS FAQ, available in the “Informational Materials” download.  From http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=d9af2c25-989c-45c4-8008-1f15722190ed:

Answer: Although every effort was made to ensure that the External Collaboration Toolkit for SharePoint provides trouble-free installation and reliable operation, it is not officially supported by Microsoft. We will provide best effort support on the SharePoint – Collaboration forum, but cannot guarantee timely resolution of any issues.

Other pertinent bits of info from the Information Materials:

• There is a suggestion that the product has been tested and is “supported” (whatever that means) only with Server 2003 (not Server 2008).
• There is a reference to the commercial product called the “External Collaboration Manager“, which I expect was developed by the same consultants that created ECTS in the first place (although I have no proof of that).

I am going to pursue aggressively a Forms-based authentication solution using ADFS as a replacement for this service.

FWIW, here is a quick breakdown on the current set of problems, and what I did to fix them:

1. When attempting to load the \sites\[sitename]\_layouts\ExternalCollaboration\aeu.aspx page (add new external user form), one user reported “Access Denied” error messages, even though he was in the site administrators list.
   • This happens because the aeu.aspx page checks to see is the currently logged in user is in the “Site Owners” group.  Of course, being a site administrator should be sufficient, but the page does not check for effective rights, but instead performs a simple ACL check.
2. Users would intermittently experience page load errors when attempting to load the same “aeu.aspx” page.  Experientation with our load balancer indicated that the problem occured on  only one of the two web front ends in our farm.  Attempts to troubleshoot by using verbose Diagnostic logging, SysInternals ProcMon, and various browser debuggers (ieHTTPHeaders, Fiddler) turned up nothing.
   • Finally, I discovered that there was a single “ExternalCollaboration.RESX” file missing in the inetpub\wwwroot\wss\VirtualServers\[IIS-site]\App_GlobalResources\ directory.  After copying the RESX file to all three production IIS sites on both web front ends, and performing an IIS Reset, the page load error went away.  I don’t believe that these files ever got replicated to the second web front end after installation, so add this step to your farm build procedure.
3. Our Account Services team reported that the “PartnerAdmin” page (or ECTS Administration web part) was reporting a “service unavailable” error.
   • This problem happened because all of the web.config files on our server reverted their “ADAMConnectionString” values to point to the pre-production host name for our ECTS LDAP service.  The event that triggered this service reversion is still unknown.  After I updated the string to point to “sharepoint.uvm.edu”, the problem was resolved.  Once again, I really need to re-install the whole solution using the correct LDAP connection string… the incorrect value is still cached somewhere in the SharePoint infrastructure that I cannot locate (most likely in configuration DB), waiting to bite me again.

Event ID: 2436
Category:  Gatherer
Description:
The start address <sts3s://sharepoint.uvm.edu/contentdbid={GUID}> cannot be crawled.

Context: Application ‘Search index file on the search server’, Catalog ‘Search’

Details:

Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (0×80041205)

Well, the service used to work, so I don’t think access rights are the real problem.  Some digging in the cloud turned up this:
http://mysharepointblog.com/post/2007/01/Windows-SharePoint-Services-(WSS)-30-Search-Setup-Notes.aspx
which sounded promising, but the proposed fix is to run a site that does not use SSL to do the gathering… I don’t think this should be necessary as again, Search used to work, and we have always had SSL.  Still, it got me thinking.

I also found this thread:
http://www.eggheadcafe.com/conversation.aspx?messageid=29143542&threadid=29102434
Which also suggests that the problem is caused by some disagreement between host names, alternative access mappings, and the “Default” security zone in SharePoint.  So I had a look at my alternative access mapping (AAMs).  Lo and behold, I had a few extra internal URLs for the default zone.  They were not supposed to be there, and were added by accident while building our new SharePoint farm.  Removing the extra internal URLs fixed the problem.

By the way, the gatherer actually can crawl SSL sites… this ability was introduced with a hotfix some time back.

In the past we accomplished this using a client-side redirect, by creating a custom 404.3 error page with a Javascript redirect. This worked well, but what if you client systems won’t support javascript (i.e. it is a webdav connection)?

Codplex to the rescue! The venerable “Ionic URL Rewrite” ISAPI filter has been updated, and published on Codeplex:
http://www.codeplex.com/IIRF
Thanks, Cheeso!

IIRF now supports the ability to return URL redirects, in addition to simple rewrites.  To use IIRF to redirect a non-SSL URL to a secure version, follow the installation instructions included with IIRF.  Then:

• Stop your production IIS site from listening on port 80 and enforce SSL usage.
• Make sure that the production site is not using host headers that would override your port settings.
• Set up a secondary IIS site which listens on port 80 only.  Add the IIRF ISAPI filter to this site.

Here is some sample entires you could use in the IsapiRewrite4.ini configration file to accomplish the redirect.  Note that [R] instead of [R=301] also works, but this performs a 302 “Temporary” redirect.  Conceptually I prefer a 301 (not that it matters because search crawlers are not hitting our Intranet sites):

# Following rule is activated if the incoming URL is not connecting to a secure port.
# Performs a Permanent Redirect (301) to the https version of the site if not secure.

RewriteCond %{SERVER_PORT_SECURE} ^0$
RedirectRule ^(.*)$ https://host.domain$1 [R=301]

# Following rule would do the same as above. I am not clear on the relative merrits of
# "HTTPS" vs. "SERVER_PORT_SECURE".

RewriteCond %{HTTPS} off
RedirectRule ^(.*)$ https://host.domain$1 [R=301]

# Yet another variation, this one simply checking the number of the port being used,
# With no validation on SSL vs. clear-text

RewriteCond %{SERVER_PORT} ^80$
RedirectRule ^(.*)$ https://host.domain$1 [R=301]

1. Denial:
   • The systems administrator refuses to accept that Cloud Computing is real, or that it is relevant to him.  He may feel that Cloud Computing is a “fad” or “passing trend”.  He may believe that Cloud offerings are simply scams.  He may labor under the false impression that her clients are unaware of Cloud offerings or do not want these services.  He may initiate the deployment of a major new messaging or collboration platform in order to prove that Cloud Computing “has got nothing that we don’t got”.
2. Anger/Resentment:
   • As time passes, more executives start asking about Cloud Computing, and more clients start using the free Cloud offerings.  It becomes impossible for the sys admin to remain in denial.  In reaction, he lashes out with anger.  He questions the intelligence of anyone who uses Google Apps.  He goes off on rants about how much “Outlook sucks” and how “Outlook Live sucks even more”.  He is deeply resentful of Cloud Computing providers for giving away for free the services he furiously has been trying to get funded for the past seven years.
3. Bargaining:
   • In this next phase the sys admin attempts to mitigate the effects of Cloud Computing though bargaining.  She may offer to “put student email into the Cloud”, but insist that faculty and staff messaging cannot leave the school network for “security and regulatory compliance reasons”.  She may sacrifice a few token applications to the Cloud (such as mail distribution lists or video conferencing), but insist that other Cloud offering are “simply not mature”.  She may cite outdated versions of service agreements as proof of her convictions.  She may request large sums of money to develop similar service offerings in-house with a more institution-friendly SLA.
4. Depression:
   • When it becomes clear that the Cloud is about to swallow his campus, the sys admin may become depressed and morrose.  He may close the door of his office to conceal the sounds of his multi-hour World-of-Warcraft “lunch breaks”.  He may stop development and maintenance on all in-house messaging and collaboration tools while asserting, “The service is dead already, what does it matter?”.
5. Acceptance:
   • When the decision is made to take advantage of Cloud Computing services, the sys admin either will revert back to step 1 (and most likely be fired), or move on the the final “acceptance” phase.  At this time, she may actually get excited about the challenging of integrating Cloud applications into the school’s identity managment system.  Countless hours will be spent debating the the merits of Python vs. Perl as the default language for scripting directory actions.  Weeks will be spent researching and implementing federated identity management systems.  Hundreds of blog entries will be posted lambasting the developers of the Cloud service and their refusal to adhere to “ieee 81516″ or “rfc 2342″.  Patches will be merged into various Web Services code trees.  As the weeks pass, the sys admins life will return to normal.  There will not be enough time or money for projects to be completed on time.  Job secuirty will continue to be assured.

Initial architecture will be something like this:

• Host: SharePoint2
  • Roles:  Web front end, Search Server query and crawl, ECTS ADAM Instance
• Host: SharePoint3
  • Roles:  Web front end, Search Server query and index, ECTS ADAM Instance
• Hosts: WinDB1 and WinDB2
  • Roles:  Back-end SQL Database failover cluster
• F5 Big-IP Local Traffic Manager (hardware load balancer)

Once initial rollout is complete, we likely will want to add:

• Hosts: WinDB1 and WinDB2
  • Reconfigured in a SQL mirrored configuration

Here is an outline of the SharePoint2/3 build procedure:

1. Install Server 2008 x64 Standard OS
   1. Activate Roles:  IIS (with ASP.NET support), AD Lightweight Directory Services (AKA AD LDS, AKA ADAM).
   2. Activate Features:  .Net Framework 3.0, PowerShell, SMTP Server
   3. Activate Feature “Desktop Experience” if you want access to “cleanmgr.exe” (Disk Cleanup wizard) and other desktop niceties.
   4. To save disk space, you might want to delete the hiberfile.sys (Hibernation file), by running “powercfg.exe /hibernate off”.
      1. Relocate the page file?
      2. Do something about WinSXS directory bloat (likely impossible without a service pack)
      3. Get IIS log files under control!
2. Configure SMTP Server using IIS 6.0 Manager.  (FTP and SMTP Services cannot be managed with the IIS 7 Manager!)
   1. Configure BadMail and Drop Box directories so that they are not located on the System volume
   2. Configure to listen only on primary server IP
   3. Configure firewall to accept SMTP conections only from our In-Mail Gateways (using external firewall in our case, but this could be done with SMTP service settings and/or the Server 2008 firewall as well). <-DON’T FORGET – SMTP is allowed to the hosts, but need to go over the config with our DNS/mail admins!
3. Install Search Server Express x64 bits:
   1. Perform “complete” install (Search Server will not install a SQL 2005 instance, as is the case with WSS installer).  Under “file location”, specify “E:\Office\12.0\Data” as the index storage location.
   2. Skip running of the Configuration Wizard after install.
4. Install SharePoint Administration Kit v2.0
   1. Exclude Profile replicator component as it will not work on WSS
5. Clone the server as many times as deemed necessary. (At present, make one clone!).  Any cloned systems must be sysprep-ed before joining the domain.  Once preped, join the computers, configure networking.
6. If planning to add this server to a load balanced cluster, install NLB feature:
   NOTE:  We will not be doing this as we plan to use F5 hardware LBs instead.
   • from “administrator” cmd shell, run “ocsetup NetworkLoadBalancingFullServer”
   • Don’t join to a production NLB cluster until SharePoint configuration is complete!
7. Replicate AD LDS (ADAM) instance to new machine, if required.
   (We need this as we are extending an existing ADAM instance to the new farm)
   1. In Server Manager, Click on “AD Lightweight Directory Services” Role,
   2. Click “AD LDS Setup Wizard”
      1. Select “A replica of an existing instance”
      2. Name the instance “ECTSInstance”
      3. Accept standard LDAP ports
      4. specify a partnerpoint server to replicate from, use standard LDAP ports.
      5. Select the “OU=ects,…” partition set for replication (this should be the only partition!)
      6. Select secondary (non-system) volume as target for AD LDS data… generally this will be “E:\Microsoft ADAM\ECTSInstance\data”
      7. Specify domain service account to run the AD LDS instance.
      8. Add “domain admins” to the AD LDS Administrators list.  Finish the wizard.
   3. Run the campus…bat file located in e:\Microsoft ADAM\ECTSInstance\data\.  This will register the Kerberos Service Principal Names required for LDP replication mutual authentication.
   4. Open the “Local Security Policy” Admin tool.  Add the domain service account to the “generate security audits” User Rights Assignment branch.
   5. Open the AD Users and Computers tool, locate the computer object on which you installed the Instance.  Give the LDS service account “create all child objects” to the computer object.
   6. Add the cluster load balanced SSL cert into the Personal certificate store of the ECTSInstance service account.
      1. Request wildcard certificate using the procedure outlined here:
         http://erlend.oftedal.no/blog/?blogid=7
         (We use the web interface for requesting a certificate, make user we use the RSA SChannel crypto provider to generate the request, use the “SHA-1” hash, use PKCS10 format, and use the “UVM – Web Server” request template.  For load-balanced LDAP servers, we must request a wildcard certificate (*.uvm.edu)
         NOTE: This step will not have to be repeated again until the current cert expires.  To add another AD LDS server, export the cert from a current server, import into the new server
      2. Export the request cert to file selecting “export all extended attributes” and “export private key” options.
      3. Import the cert into the “Personal” branch of the service account’s certificate store on the target server.  Make sure that you import “all extended attributes”, and the private key.  Do not select the use of advanced encryption password.
      4. Restart AD LDS and test SSL connections.
      5. If all is not working (as is the case with one of my two servers), here is where we get into undocumented territory.  Here are some helpful resources for debugging:
         1. I set SChannel diag logging to verbose :
            • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel
              REG_DWORD EventLogging, value 0×7
            • Restart ECTSInstance, look for “SChannel” entries in the server “application” even logs.  These logs will tell you which certificate the system attempted to use, and why access failed.
         2. You may need to add the wildcard cert to the Local Computer Certificate Store as well… run MMC, add the “Certificates” snap-in for “Service Account”, using the “ECTS Instance” service.  Navigate to the “Personal” branch, run an import action, import the wildcard with all extended attributes and the private key.
         3. Now locate the physical copy of this cert in c:\programdata\microsoft\crypto\RSA\MachineKeys (it will be the file with the most recently modified time stamp).  Add “read/execute” permissions to this file for the AD LDS service account, then restart the LDS instance.
   7. Force mutual authentication for replication traffic:
      1. Run ADSI Edit
      2. “Connect to”, enter the AD LDS server name in the Computer field, select the “Configration” well-known naming context.  As documented in http://technet.microsoft.com/en-us/library/cc794841.aspx, get “properties” on the “CN=Configuration…” partition, and change the value of “msDSReplAuthenticationMode” to “2”.
   8. Set local password policy – this controls password policy of AD LDS accounts:
      1. Add the Sharepoint server computer account to the “ETS – SharePoint Password Policy” GP Object.  After running “gpupdate /target:computer /force”, verify the settings by doing the following:
         1. Open Local Security Policy control panel
         2. Expand “Account Policies”->”Password Policy”
         3. Settings applied should follow the 1/365/0/8/Disabled/Disabled format.  (we may want to revisit this policy later).
8. Run the SharePoint Products and Technologies Configuration Wizard:
   1. Connect to an existing Farm
   2. Enter “WINBD” as the database server.  The wizard will correctly select “SharePoint_FarmConfig” as the configuration database.  The correct service account username will be provided… you need to enter the password.
   3. Click “Advanced Settings”, specify that you which the server to host the Central Admnistration site.
      1. If setup fails with the error:
         “SharePoint Configuration Wizard failed with an exception “Error during encryption or decryption. System error code 997″
         A solution can be found here:
         http://blogs.msdn.com/priyo/archive/2007/08/11/add-new-sharepoint-server-to-existing-server-farm-an-unhandled-exception-occurred-in-the-user-interface-exception-information-unable-to-connect-to-the-remote-server.aspx
         Essentially we just run “stsadm –o updatefarmcredentials –userlogin “domain\service_acount” –password <thePassword>” on the first SharePoint server, then re-run the wizard.
   4. Update the “Central Admin” shortcut to point to the local Central Admin site by doing the following registry hack:
      http://blogs.technet.com/wbaer/archive/2007/08/30/sharepoint-3-0-central-administration-url-on-multiple-web-front-end-servers.aspx
      Essentially, edit the key:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS
      Then locate CentralAdministrationURL and change it to point to the local server.
9. Configure Search Service:
   1. When Search is run in an environment where SharePoint services are accessed from a FQDN which is different from the physical host name (i.e. our environment, or any other environment with load balancers), you will need to work around the “loopback security check” feature of Windows.  Failing to do so will result in “access denied” errors in the crawl logs.  My thanks to Shawn Feldman for discovering this:
      http://blogs.msdn.com/fledman/archive/2008/09/18/access-denied-with-windows-server-2008-and-moss-when-crawling.aspx
      The relevant work-around is documented here (see “Method 2”):
      http://support.microsoft.com/kb/896861
      We simply need to add the public FQDN of our SharePoint server to:
      Key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
      Value: REG_MULTI_SZ, sharepoint.uvm.edu
      And then restart the IISAdmin service.
   2. Open the search admin page from SharePoint Central Administration:
      1. Access Crawling –> Content Sources
         1. Click the “Local Office SharePoint Server sites” default source.
         2. Define a crawling schedule for the SharePoint application
         3. Click “new content source” to add any additional content sources that are desired (i.e. our production file servers).
         4. Define additional crawl schedules for these new content sources.
         5. Set up “Crawl Rules” to exclude any directories from the content sources that you do not wish to have indexed.  In our environment, it was essential to exclude the “~snapshot” directories from the root of our NetApp file shares.
   3. Add Search Center to our SharePoint landing page:
      1. Create a new sub-site of type “Enterprise Search”
      2. Tune federated results by adding/removing web parts to the results page
   4. Add Federated Locations for additional search results:
      Ideally we would like to add results from out “GoogleWeb.uvm.edu” search appliance, and perhaps a Google “site” search for other close University partners
      1. For GSA (Google Search Appliance) Federation, it appears we will need to setup an RSS Transform:
         1. http://enterprise-code-samples.googlecode.com/svn/trunk/rss-stylesheet/Readme.htm
            http://enterprise-code-samples.googlecode.com/svn/trunk/rss-stylesheet/
         2. As the readme above recommends, we set up a new “front end” on the GSA for RSS results.  We called this Front End “RSS”.  We edit the “base_url” value to point to http://googleweb.uvm.edu/Search?. We then visit this URL and perform a query.  We take the resulting query results URL:
            http://googleweb.uvm.edu/search?q={searchTerms}&entqr=0&output=xml_no_dtd&sort=date%3AD%3AL%3Ad1&lr=&client=uvm2008&ud=1&oe=UTF-8&ie=UTF-8&proxystylesheet=uvm2008&site=default_collection
            and we substitute the name of our Front End in the place of the “proxystylesheet” and “client” values.  I also simplify the query just a bit as follows:
            http://googleweb.uvm.edu/search?q={searchTerms}&output=xml_no_dtd&lr=&client=rss&ud=1&oe=UTF-8&ie=UTF-8&proxystylesheet=rss&site=default_collection
         3. We then use the RSS query URL above as the template URL for a federated search query in the SharePoint Search Center.
         4. We edit the search results page to include federated results, and specify the “UVM GoogleWeb Search” federated location in the “Location” of the Federated results web part (using the “Modify Shared Web Part” command).
   5. Integrate Windows Search desktop tool with Search Server:<- Not yet done, but this can wait until after the production cut-over.
      
      1. Approve Windows Desktop Search 3.0->Windows Search 4.0 update on WSUS server
      2. Deploy Group Policy templates for Windows Search 4
      3. Configure:
         http://technet.microsoft.com/en-us/library/cc732491.aspx#BKMK_Addprimaryintranetsearch
10. Install Infrastructure Update for WSS3 x64:
    1. Initiate the update on the first node in the cluster.
    2. When prompted, start the install on the second cluster node.
    3. When the configuration wizard completes on the second node, go back to the first and allow configuration to complete.
11. Install Infrastructure Update for Search Server x64:
    1. Initiate the update on the first node in the cluster.
    2. When prompted, start the install on the second cluster node.
    3. When the configuration wizard completes on the second node, go back to the first and allow configuration to complete.
12. Clean up IIS settings for the newly created Web Sites – configure binding, authentication and SSL  (Note that these procedures are only accurate when using Windows-native load balancers… when we transition to f5 load balancing, it will not be necessary to return custom errors from IIS as the f5 will handle HTTP-to-HTTPS redirections.) :
    1. SSL Cert Installation:
       Install SSL certs into “Personal” Store of the Computer account using the “Certificates” MMC snapin.
    2. Binding:
       Open the IIS Manager MMC snapin.  On each site, right-click and select “edit bindings”:
       1. For site “SharePoint – 443” (which represent the traditional “sharepoint.uvm.edu” URL), bind https and http protocols to port 80 and port 443, using the IP address for “sharepoint.uvm.edu” (132.198.102.12).  When binding SSL, select the appropriate cert from the “SSL Certificate” drop down menu.
       2. For “SharePoint – Internet” (which represents SharePointLite), bind https and http, ports 443 and 80, to “sharepointlite.uvm.edu”, IP 132.198.102.36.  Again, select the correct SSL cert for this site.
       3. For “SharePoint – Extranet” (which represents PartnerPoint), bind https and http, ports 443 and 80, to “partnerpoint.uvm.edu”, IP 132.198.102.49, selecting the matching SSL cert once again.
    3. SSL Configuration:
       1. In IIS Manager, open the “features view” for each site.
       2. Double-click “SSL Settings”
       3. Check “Require SSL”, leaving the default “ignore Client certificates” setting.
       4. Now double-click the “Error Pages” item for the server root.  Add a custom error for 403.4 (SSL required), pointing to our custom “redirect.html” javascript file.  We will need to have copied this file into “c:\inetpub\custerr\en-US\” before completing this step
       5. Now find the applicationHost.config file for the IIS server.  This should be located in “C:\Windows\system32\inetsrv\config”.  Locate the section for each site that serves SharePoint content (i.e. <location path=”SharePoint – 443”>), then locate the <httpErrors> tag under <system.webServer>.  In the httpErrors tag, change the value for “existingResponse” from “PassThrough” to “Replace” (response “Auto” also seems to work, but may produce inconsistent results).  This will prevent ASP.NET from replacing the 403.4 error response from the IIS server.  I am much indebted to this forum thread for this breakthrough:
          http://forums.iis.net/t/1113734.aspx
          Also helpful was the new “failed request tracing” module in IIS7:
          http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis7/
          More information on the meaning of the various existingResponse values can be found here:
          http://blogs.iis.net/ksingla/archive/2008/02/18/what-to-expect-from-iis7-custom-error-module.aspx
13. Install the MS FilterPack 1.0 (Search Server can already index most Office 2007 documents, but this adds ability to index inside of One Note files and ZIP archives):
    1. Follow instructions at:
       http://support.microsoft.com/?id=946336
14. Install Adobe iFilter, with 64-bit “thunking” DCOM service:
    • http://labs.adobe.com/wiki/index.php/PDF_iFilter_8_-_64-bit_Support
    • http://workerthread.wordpress.com/2008/07/18/adobe-reader-9-available-works-fine-with-sharepoint/
    • http://servergrrl.blogspot.com/2008/01/and-now-for-something-completely.html
    • TEST IT… Internet chatter suggests that this config is less than reliable.
15. Install MindManager extensions.
    1. DEPRECATED – We will discontinue this extension with the new upgrade as it does not work with MM v7 or v8
16. Install ECTS components on each web front end server.
    • Having problems with installation script… what if we try the ECTS update available though CodePlex???
      1. If using updated ECTS files, it will be necessary to update the PartnerAdmin and PartnerConfig pages, as the self-service Site Collection Manager.  The existing pages will not work because the GUIDs on the Web Parts have changed.
      2. The ects_setup_sharepoint.vbs script still fails using the updated code… Since the codeplex team has not documented their changes, I think we will skip this option.
    • Troubleshooting issues:
      1. The ects_setup_sharepoint.vbs script succeeds in installing the ECTS solution, but fails when activating site features.  I suspect that “cscript” on Server 2008 is not processing return codes from stsadm.exe correctly, and this is reporting failure to install features (I am not positive about the reason for the script failure, although it certainly is not a result of stsadm.exe being broken.
         I was able to work around this problem by opening the ects_setup_sharepoint.vbs file in a text editor, searching for the error string that was sent to the console when the script failed, then running all of the operations in the script manually from that point forward.  Fortunately, all of the stsadm commands in the script are successful when run from the command line.
      2. ECTS is not compatible with MS Load Balancing out of the box.  I switched to a F5 load balancer before working through the problem.  It is possible that the problem I was having could have been fixed with the same “loopback security check” that caused problems during our F5 configuration
         http://support.microsoft.com/kb/896861
         In fact, we may have had the problem even with the f5 in place, but I would not know because I applied the loopback fix before implementing the F5.
         The error codes suggest that a login failure is occurring between the IIS application and the AD LDS LDAP instance.  When I try to connect to the load-balanced LDAP DNS name using the “LDP.exe” LDAP client, I also get an authentication error.  However, when I connect to the local server address, authentication works.
      3. As was the case when I first installed ECTS, the web.config files required a bit of hand-tuning to get services working correctly:
         http://www.uvm.edu/~jgm/wordpress/?p=112
         Once again, I had to modify the “ADAMConnectionString” in the web.config of each IIS site to reflect the actual DNS name of the load-balanced AD LDS servers.  I had installed ECTS using a different name initially, and the ECTS un-installation script did not clear out these values.
      4. I did find it necessary to deactivate all ECTS site collection features, re-activate them, then perform an IIS reset before my existing ECTS management pages would work again.  This seems pretty par for the course when removing and re-installing SharePoint solutions.
      5. After connecting the production content database and changing the URL for the server, I also needed to edit “LDAPHost” value to reflect the production name of the server in the “TEMPLATE\FEATURES\ECTSBase\Feature.xml” file (located in the “12″ hive).  This value was set at the time that ECTS was deployed to the server.  I expect that the same (wrong) LDAPHost value would get replicated to additional ECTS servers if we were to add new ones, because this setting is contained in the RESX package that gets built by the ECTS installer, and cached in the database for future deployment.  I expect I would need to do a full retract/remove/redeploy to fix the problem permanently.
17. Install Globally-deployable solutions from the “fab 40” application template.  If you deploy a web front end into an existing farm, the files required by these features will get transferred automatically.  However, when building a new farm, we need to install them manually.  Currently required “server admin” templates are:
    • ApplicationTemplateCore
    • ChangeRequest
    • ContactsManagement
    • DocumentLibraryReview
    • EventPlanning
    • HelpDesk
    • InventoryTracking
    • ITTeamWorkspace
    • Knowledgebase
    • LendingLibrary
    • PhysicalAssetTracking
    • ProjectTrackingWorkspace
    • RoomEquipmentReservations
    • Procedure:
      • stsadm -o addsolution -filename <file_path>\<template_name>.wsp
      • stsadm -o deploysolution -name <template_name>.wsp –allowgacdeployment
18. Install radEditor:
    1. Install ASP.NET Ajax for .NET 2.0, version 1.0
    2. Follow the Ajax configuration for SharePoint configuration guide found here:
       http://sharepoint.microsoft.com/blogs/mike/Lists/Posts/Post.aspx?ID=3
    3. Install radEditor using the included instructions.
    4. Copy radEditor configuration files from an existing production server to the new server:
       1. In the directory:
          ”C:\Program Files\Common Files\Microsoft Shared\web server extensions\wpresources\RadEditorSharePoint\[versionString]\RadControls\Editor”
          Backup the existing ListConfigFile.xml, ConfigFile.xml, ListToolsFile.xml, and ToolsFile.xml files.  Replace with versions customized for UVM.  Note that the MOSS LinkManager tool does not work in WSS.  Also note that when editing list content that does not support “Enhanced Content”, the first toolbar in the ListToolsFile.xml will be removed… in past versions, the toolbar named “enhancedTools” was removed.
       2. Copy the files ListConfigFile.xml, ConfigFile.xml, ListToolsFile.xml, and ToolsFile.xml to all other nodes in the cluster.
       3. perform an IISRESET.
       4. Update ONET.xml files in the “12” hive to activate the radEditor feature by default in all new sites (see ONET.xml template files on the prod web front end for examples).
          NOTE that the “RadEditor for non-IE browsers” and “RadEditor for IE” features have been collapsed into one unified feature.  Update the ONET.XML files accordingly!  (note that the feature ID for the main RadEditor List editor has not changed… only it’s name is different.  We did not have to insert a new default feature ID, but we did need to remove the “RadEditor for IE” feature because it is no longer present in RadEditor MOSS.)
       5. Run:
          stsadm –o uninstallfeature –name RadEditorFeatureRichHtml.
          This “Web Content Management” feature is not supported in WSS, so we may as well remove it to avoid confusion.
       6. Deactivate and then re-activate the radEditor features on at least one existing site, and test functionality.
19. Install “Smiling Goat” Feed Reader (RSS/ATOM subscriber web part)
    1. This will require Feed Reader users to update their web parts!
    2. Current release here:
       http://www.codeplex.com/FeedReader/Release/ProjectReleases.aspx?ReleaseId=19830
       (version 3.1.0.1 at the time of this writing)
20. Install SharePoint Training Kit:
21. Tune web application settings to match production server:
    1. In “Operations”:
       1. Configure blocked file types – in our case we have been requested to all “MAT” files.  MAT is one of may obscure Office file extensions, but also is used by MatLab, a common mathematical/statistical application used on campus.
       2. Enable Usage Analysis Processing – relocate log files off of the system volume.
          1. You MUST grant read/write access to the local WSS_WPG to the folder that will hold the usage analysis logs.  If you fail to do so, you will see lots of errors in the Diagnostic Logs allong the lines of “Cannot create folder “<big ugly hexidecimal number>”".
       3. Configure incoming and outgoing email settings.
          1. Incoming mail requires SMTP to be installed on the server – managed with the old-school IIS 6.0 Manager MMC.
          2. We needed to use the “Advanced Settings” to specify the SMTP drop folder in the Incoming Mail settings page of Central Administration.  SharePoint diagnostics logs indicated that the timer service could not determine the drop folder location automatically.
          3. After configuring the mail drop folder, SharePoint still was unable to process messages.  “Access denied” events started queuing up in the event viewer.  A quick analysis using SysInternals ProcMon shows that the WSS Access account (being used by the OWSTIMER.EXE process) has no ability to access the drop folder defined above.  I just added “modify” access for that account to the drop folder, and incoming mail started processing immediately.
    2. Under “Application Management”:
       1. Tune the “Web application general settings”:
          1. Set upload limits for files
          2. Set time zone
          3. Set quota templates for new sites
       2. Config “site use confirmation and deletion”. <- Be sure to do this after PROD cutover!!!  Can’t do it ahead of time as users will start to get email from the pre-prod server!
       3. Enable self-service site creation. <- Also needs to be done after prod cut-over
       4. Configure “policy for web application” to allow selected groups of SharePoint administrators rights to all sites in the farm.
    3. Edit the footer of the “welcome” email message starting at line 5219 of “core.en-US.resx” in the 12-hive “resources” folder.  Replicate on all web front ends in the farm.
22. Configure f5 load balancers:
    1. Lots of IP addresses required:
       1. “floating ip” for network on which F5s will communicate with the SharePoint web servers.
       2. 2x Self-IPs for the physical interfaces on the F5s which will handle the floating IP
       3. 3x IP addresses for the public SharePoint URLs (standard, lite, partner)
       4. 6x IP addresses for the private interfaces on each web server node (for standard, lite, and partner sites, one each on two web servers)
    2. Need to generate SSL Certificate/Key pair files for the load balancer “SSL Profiles” (the F5 uses separate files for certificates and keys, as opposed to IIS which uses a single CER file – we need to split the IIS files and upload to the F5.
       1. Using the certificate manager MMC snapin, export the production certs to PFX (PKCS #12) files (make sure to specify that you wish to export the private key, otherwise PKCS #12 is not an option in the wizard).
       2. Convert the pfx file into a PEM using the openssl executables (available for Windows here: http://www.slproweb.com/products/Win32OpenSSL.html) using the folowing command:
          openssl.exe pkcs12 -in [infile].pfx -out [outfile].pem -nodes
          (You will be prompted to enter the password for the PFX, if it has one.  The “-nodes” flag indicates that the output file will not be encrypted with a password)
       3. Open the PEM file created above with a text editor.  Remove the  private-key portion of the file (all content from “Bag Attributes” to “—–END RSA PRIVATE KEY—–”) and paste this into a separate “KEY” file (UNIX-style line endings, ANSI-encoded).
       4. Upload the new PEM and KEY files into your F5 load balancer to create a new SSL client profile.
    3. Set up two virtual servers for each SharePoint URL – one to redirect HTTP to HTTPS, one to handle regular traffic.
       1. Add the following iRule to perform the SSL redirect, and attach it to the Virtual Server listening on port 80:
          (This rule will redirect your browser to https://sharepoint.uvm.edu from either http://sharepoint or http://sharepoint.uvm.edu… well, actually it will redirect any non-HTTPS connection to a HTTPS version of itself, appending our domain “.uvm.edu” if it is missing.)

             1: when HTTP_REQUEST {

             2:   if { [HTTP::host] == "*.uvm.edu" } {

             3:     HTTP::redirect https://[HTTP::host][HTTP::uri]

             4:   } else {

             5:     HTTP::redirect https://[HTTP::host].uvm.edu[HTTP::uri]

             6:   }

             7: }

23. TEST TEST TEST:
    1. Test each feature on both web front ends by alternately disabling the nodes in the load balancer configuration.
    2. Test again with both nodes enabled… watch for authentication and session persistence issues.
    3. Test all features in each access mapping – SP, SPLite, and Partner… web.config file variations could cause problems!
24. Consider Deployment of “Group Board 2007” and “Sample Master Pages”:
    • http://www.microsoft.com/sharepoint/templates.mspx

And to complete the cutover:

1. Redirect SharePoint traffic to a “maintenance underway” page, or just put the service in read-only mode.
2. Backup the current production content database
3. Detach the content database from the production server.
4. Attach the content database to the new servers
5. Change the SSL profiles used on the F5 load balancers to use the production certs.
6. Take down the original SharePoint IIS server and disable.
7. Change the listening port on the F5 load balancers to match the production server IPs.
8. Configure Zone security and Alternative Access Mappings for the Farm to reflect the new production names:
   1. Make sure that https://sharepoint.uvm.edu, https://sharepointlite.uvm.edu, and https://partnerpoint.uvm.edu are all listed as “Public URLs” for the farm.
   2. Make sure that the HTTP equivalents of these URLS are listed as INTERNAL URLS in the AAM table if you are performing SSL termination on the load balancers.
9. Contact SAA Mail admins to update the mail server LDAP records for SharePoint mail routing
10. Dredge though this post for things that will need to be configured after the migration, and test mercilessly.

• Randomly generated initial password is too complex – data entry errors cause login denial
• Password expiration errors are not transparent – We need to capture the error that is seen in a password expiration instance.
• Passwords generated by ECTS (either during account creation or a ECTS admin reset) are temporary and must be changed on next login.  The account attribute “eatmuPwdGenerated” holds this information.
• Password strength requirements are not displayed in the forms, and password strength errors are not detailed or helpful (i.e. they do not tell you why your password is unacceptable).
• Login errors are not detailed or helpful – they do not tell you if the account is locked or disabled, it the password is expired, or if you simply entered an invalid username/password combination.
• Even when login is successful, users often will get “access denied” messages because of permissions problems:
  • The ECTS “Add External User” dialog generally refuses to add permissions to the ACL for a site… it only works consistently when you add the user to an existing site group
  • Sign-in for ECTS users requires at least “Read” permissions to the to-level site in a site collection.  You cannot grant external users rights to a child site with no permissions in the parent.

Clearing account lockouts – accomplished by setting the “lockoutTime” attribute of the AD LDS account to “0”.  This causes the “badPwdCount” attribute to be reset to zero.  Note that you cannot set “badPwdCount”, nor “badPasswordTime” as these attributes are owned by “SYSTEM”, and thus cannot be edited manually.  Solution located in the “EggHead Cafe”:
http://www.eggheadcafe.com/forumarchives/windowsserveractive_directory/nov2005/post24794404.asp

Other AD LDS account attributes to watch – see MSDN Active Directory Schema documentation for details:
http://msdn.microsoft.com/en-us/library/ms675090(VS.85).aspx

• eatmuPwdGenerated – attribute added by ECTS installer.  Indicated whether current password was generated by ECTS, or by the user.  Reset when the user successfully logs in and sets his own password.
• msDS-UserPasswordExpired – populated, but apparently not accurate or used.
• msDS-User-Account-Control-Computed – Most commonly used for reporting on account state.  This value is computed from other fields, and should not be modified directly.
• pwdLastSet – in active use for ECTS accounts, uses “Large Integer” value, formatted as “NT Time”, or number of 100 nanosecond intervals from 1 Jan, 1601.  This can be converted to a readable date using “w32tm.exe /ntte [string]”.  This value cannot be reset to a specific value, although you can use the special values “0” (meaning “must change at next login”) or “-1” (meaning “now”); however, ADSI Edit does not allow you to enter the value of “-1”, so we would have to use a different tool to set a “-1” value.  Setting the value to “0” will break login as there is no LDAP method for requesting a password change.

I found the answer though our friends in the TechNet Social:
http://social.technet.microsoft.com/Forums/en-US/sharepointcustomization/thread/e4a34a49-af24-4437-8148-2bd6237013c0/

Who in turn got if from the venerable EggHead Cafe:
http://www.eggheadcafe.com/software/aspnet/30212653/how-to-change-welcome-mai.aspx

To summarize, modify the HTML code starting at line 5219 of the following RESX file in your “12” hive:
C:\Program Files\Common Files\Microsoft Shared\web server\extensions\12\Resources\core.en-US.resx

I decided to see if I could automate installation of wireless profiles using a script.  Three days later, I have the outline of something that appears to work…

Below you will find a VBScript that performs the following procedures:

• Detects the operating system platform and Service Pack levels
• Installs the trusted root certificate that is used by our RADIUS server if it is not already present.  The script calls the “certmgr.exe” tool, available from the Windows Platform SDK (I suppose I could have used CAPICOM, but why should I torture myself?)
• On Windows XP, uses the free utility “zwlancfg.exe” written by ENGL to install our WPA2-Enterprise wireless profile.  The script will install the KB918997 HotFix if it is not already present.  This HotFix adds the WiFi API to Windows, allowing programmatic configuration of wireless on XP Service Pack 2 (Note: XP Service Pack 3 includes this HotFix).
  (I configured a WiFi profile on my XP laptop then used the command:
  zwlancfg.exe /export:”[profile name]”
  to generate the XML profile called by the script.
• On Windows Vista, we call “netsh wlan import profile” to import a WiFi profile that was generated using:
  netsh wlan export profile –name:”[profile name]” –folder:”[export folder]”

No doubt there are smarter ways to do this, and essential script logic that I am missing.  I welcome your feedback and recommendations on how this script can be enhanced.  Code follows:

option explicit
'Install UVM WPA2 wireless profile
' Supported platforms:  Windows Vista and XP with Service Pack 2 or 3
' Requires external tools: "zwlancfg.exe", "CertMgr.exe" (from the Windows Platform SDK), and HotFix installer for KB918997
' Requires external files:  "IPS Servidores" root certificate file, XML configuration files for XP and Vista

' create constants
const cNetName = "wpa2"
const cLogFile = "uvm_wpa2.log"

' declare variants
dim oShell, oUserEnv, oFSO, oFile
dim iSPVer
dim sTempEnv, strComputer, sOS
dim bSuccess

'define variants
bSuccess = false
strComputer = "."

'instantiate global objects
set oShell = WScript.CreateObject("WScript.Shell")
set oFSO = CreateObject("Scripting.FileSystemObject")
sTempEnv = oShell.ExpandEnvironmentStrings("%TEMP%") & ""
set oFile = oFSO.CreateTextFile(sTempEnv & cLogFile,true)

fDetectOS sOS, iSPVer

if inStr(sOS, "Vista") > 0 then
    subInstCert
    subImpVistaProfile
    elseif inStr(sOS, "XP") > 0 then
        if iSPVer = 2 then
            subXPPatch
            subInstCert
            subImpXPProfile
        elseif iSPVer = 3 then
            subInstCert
            subImpXPProfile
        else
            oFile.WriteLine "Your operating system is not supported for use with this script."
            WScript.Quit -4
        end if
    else
end if

oFile.close

'''''''''''''''''''''''''''''''''
''' begin environment cleanup '''
'''''''''''''''''''''''''''''''''
set oFile = nothing
set oFSO = nothing
set oUserEnv = nothing
set oShell = Nothing
''''''''''''''''''''''''''''''''''
''''' end environment cleanup ''''
''''''''''''''''''''''''''''''''''

function fDetectOS(sOS, iSPVer)
'Detect OS Function - detects OS Caption string and Service Pack integer from WMI WIN32_OperatingSystem.
'Expects to varibles passed, returns the full OS Caption String, and SP Major Version intger
    'Declare variables
    dim colItems
    dim objWMIService, objItem
    'Instantiate local objects/collections
    Set objWMIService = GetObject("winmgmts:" & strComputer & "rootCIMV2")
    Set colItems = objWMIService.ExecQuery("Select * from Win32_OperatingSystem")

    For Each objItem in colItems
      sOS = objItem.Caption
      oFile.Write "Detected Operating System: " & sOS
      iSPVer = cInt(objItem.ServicePackMajorVersion)
      oFile.Write "Detected Service Pack Version: " & iSPVer
      oFile.Write "Service Pack Minor Version: " & objItem.ServicePackMinorVersion
    Next

    'Clean local objects/variables
    set objItem = nothing
    set colItems = nothing
    set objWMIService = nothing
end function

sub subImpVistaProfile
'Imports Vista Wireless Profile using NETSH command.  
'Requires: a Vista wifi profile file exported using NETSH, defined in cVistaProfile within this function
    const cVistaProfile = ".uvm-wpa2-test.xml"
    const cUserScope = "all"

    dim iStrMatch
    dim oExec, oStdOut
    dim sStdOutLine

    oFile.WriteLine "Executing command: netsh wlan add profile filename=""" & cVistaProfile & """ user=" & cUserScope & ""
    set oExec = oShell.Exec("netsh wlan add profile filename=""" & cVistaProfile & """ user=" & cUserScope & "")
    set oStdOut = oExec.stdOut
    While not oStdOut.AtEndOfStream
        sStdOutLine = oStdOut.ReadLine
        oFile.WriteLine(sStdOutLine)
        iStrMatch = cInt(inStr(sStdOutLine, "Profile " & cNetName & " is added on interface"))
        if iStrMatch > 0 then
            WScript.Echo "The " & cNetName & " wireless profile was added successfully to your system"
        elseif iStrMatch = 0 then
            WScript.Echo "The wireless profile failed to import.  Please see the manual profile " _
            & "configuration instructions available at http://www.uvm.edu/ets/wireless/wpa/.  A " _
            & "log file named " & cLogFile & " which contains the full error message can be " _
            & "found in the " & sTempEnv & " directory."
            WScript.Quit -3
        End If
    Wend

    set oStdOut = Nothing
    set oExec = Nothing
end sub    

sub subImpXPProfile
    ' Installs an XP wifi profile using zwlancfg.exe.  Requires the HotFix KB918997 be installed on the system before running.
    ' Requires presence of xml wifi profile file defined in cXPProfile
    const cXPProfile = ".wpa2.xml"
    const cForReading = 1
    Dim oZFile
    Dim sZFile

    oFile.WriteLine "Executing command: zwlancfg.exe /import:""" & cXPProfile & """ /log"
    oShell.Run "zwlancfg.exe /import:""" & cXPProfile & """ /log", 1, true

    set oZFile = oFSO.OpenTextFile("zwlancfg.log", cForReading)
    sZFile = oZFile.ReadAll
    oZFile.close

    oFile.WriteLine "Output from zwlancfg.exe follows..."
    oFile.Write sZFile

    iStrMatch = cInt(inStr(sStdOutLine, "Profile added to interface"))
    if iStrMatch > 0 then
        bSuccess = true
        WScript.Echo "The " & cNetName & " wireless profile was added successfully to your system"
    else WScript.Echo "Import of the WPA2 profile for XP failed.  Please see the manual profile " _
        & "configuration instructions available at " _
        & "http://www.uvm.edu/ets/wireless/wpa/.  A log file named " & cLogFile & " which " _
        & "contains the full error message can be found in the " & sTempEnv & " directory."
        WScript.Quit -1
    End If
end sub

sub subXPPatch
    stop
    const cHotFixID = "KB918997" 'IS THIS HOW THE HOTFIX IS DISPLAYED BY THE WMI QUERY?  nEED TO TEST!!!
    dim colItems
    dim objWMIService, objItem
    dim iRC
    dim sHFOut
    dim bHFPresent

    bHFPresent = false

    Set objWMIService = GetObject("winmgmts:" & strComputer & "rootCIMV2")
    Set colItems = objWMIService.ExecQuery( _
        "SELECT * FROM Win32_QuickFixEngineering",,48)
    For Each objItem in colItems
        sHFOut = objItem.HotFixID
        if sHFOut = cHotFixID then
            bHFPresent = True
        end if
    Next
    oFile.WriteLine "QFE HotFix ID " & cHotFixID & " is present: " & bHFPresent
    if bHFPresent = false then
        oFile.WriteLine "We now will attempt to install QFE HotFix 918997."
        iRC = oShell.Run("WindowsXP-KB918997-v6-x86-ENU.exe /passive /noreboot", 1, true)
        oFile.WriteLine "Return code from HotFix installer: " & iRC
        if iRC = 0 then 'IS THIS THE ACTUAL RETURN CODE FOR A SUCCESSFUL INSTALL???
            WScript.Echo "A patch to your operating system was required to enable Wireless " _
            & "access to the UVM network.  The patch was applied successfully.  Please reboot " _
            & "your system and run this script again to complete Wireless configuration."
        else WScript.Echo "Application of the required XP HotFix " & cHotFixID & " " _
            & "failed.  Please see the manual profile configuration instructions available at " _
            & "http://www.uvm.edu/ets/wireless/wpa/.  A log file named " & cLogFile & " which " _
            & "contains the full error message can be found in the " & sTempEnv & " directory."
            WScript.Quit -1
        end if
    end if

    set objItem = nothing
    set colItems = nothing
    set objWMIService = nothing
end sub

sub subInstCert
    stop
    'const cRootName = "IPS SERVIDORES"
    'dim oAllCerts, oCert
    'set colCerts = oCerts.Find(CAPICOM_CERTIFICATE_FIND_ROOT_NAME, cRootName, true)
    'oCert.Load(fileName, CAPICOM_KEY_STORAGE_DEFAULT, CAPICOM_LOCAL_MACHINE_KEY)
    dim iRC
    iRC = oShell.Run("certmgr.exe -c -s -r localMachine root | find ""IPS SERVIDORES""", 1, true)
    if iRC = -1 then
        oFile.WriteLine "Root Certificate for IPS_SERVIDORES needs to be installed.  Attempting install..."
        iRC = oShell.Run("certmgr.exe -add -c IPS_SERVIDORES.cer -s -r localMachine root", 1, true)
        if iRC = 0 then
            oFile.WriteLine "Certificate installed successfully"
        else
            WScript.Echo "Certificate failed to install... You will need to install the " _
            & "certificate manually.  See the instructions at https://www.uvm.edu/ets/wireless/wpa2 " _
            & ", then run this script again to compelte installation of the UVM wireless profile."
            WScript.Quit -2
        end if
    else
        oFile.WriteLine "Root Certificate for ""IPS SERVIDORES"" is already installed."
    end if
end sub

http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en

LogParser lets us run SQL-like queries against the contents of many different types of structured data files, including CSV, TSV, XML, W3C, IIS, and many others.  Output can be formatted in almost as many ways, including to a GUI dataview window. Anyone who likes SQL queries will love this.

Below is a simple sample conversion that I ran to strip out all “Medium” rated alerts, and anything that was not generated by the SharePoint Search Services.:

LogParser.exe -i:TSV -o TSV "SELECT Timestamp, Process, Area, Category, Level, Message
INTO searchEvents.tsv from 'c:\Program Files\Common Files\Microsoft Shared\web server
extensions\12\LOGS\SHAREPOINT1-20081111-1237.log' WHERE Area='Search Server Common'
AND Level<>'Medium'"

First, we had to grab the BitLocker Recovery Tool from Microsoft:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4FFD0D16-A51B-48B1-9042-AE1FB2DE40C6&displaylang=en

I installed the tool onto a Vista desktop, and connected my laptop drive to the system using a SATA-to-USB converter, such as the one seen here:
http://insidecomputer.stores.yahoo.net/seatasatousb.html
That worked really well… my BitLocker-encrypted drive immediately became visible to Windows, although it (quite naturally) could not be read.

I then ran repair-bde.exe, providing the BDE recovery key which I had escrowed in Active Directory.  I used the option to extract the recovered data to an image file on my external ieee1394 drive.  Repair-bde dutifully extracted the drive contents to a file, and reported success.

Now the tricky part… how do we read this massive image file?  It does not appear to be a WIM file (i.e. “imagex /mount” claims that this is not a valid WIM image).  It cannot be mounted as an ISO, nor can it be extracted using any of the archive handlers supported by 7-zip.  It cannot be mounted as a virtual disk using Virtual PC.  What is it???

I contacted Microsoft support to find out… support claims that I should use “IMGMOUNT.EXE” to mount the image.  Some Googling suggests that this utility is part of the short-lived “Automated Deployment Services”, or “ADS” product that Microsoft released to allow deployment of Windows Server 2003 images:
http://www.microsoft.com/downloads/details.aspx?FamilyID=D99A89C9-4321-4BF6-91F9-9CA0DED26734&displaylang=en

So I downloaded ADS, and did a “custom” install, and selected the “image creation tools”.  This installed “IMGMOUNT.EXE” on my system, in the “%ProgramFiles%\Microsoft ADS\bin” directory.  Unfortunately, IMGMOUNT also reports that this is not a valid image.  Microsoft support also told me that the third-party tool “ISOBuster” should be able to mount the image:
http://www.isobuster.com/
But this failed to work, too.  I guess the image generated by Repair-bde.exe simply was not valid.

Oh well, by this time, my laptop has been repaired and I was able to get back into my OS using the BitLocker recovery password.  I guess the takehome lesson is not to use the recover-to-image option of the repair-bde tool… instead, recover to the root on an external drive.  This may not work any better, but at least you will know immediately if the utility is successful in decrypting your drive contents.

The other problem that I ran into was the fact that I lost my TPM chip with the motherboard.  As you may know, your BitLocker decryption keys are stored on your TPM, and that your TPM cannot be detached from your motherboard.  New motherboard=new TPM.  Oh well… It looks like I need to turn off BitLocker on my system, decrypt the whole drive, and then re-activate BitLocker.  There does not appear to be a way to write the BitLocker decryption keys to the TPM once the drive is already encrypted… Bummer!

Decision Points:

Need to decide…

• Where to host ADAM – We want it replicated for additional fault tolerance:

• The best option may be to run it on each SharePoint server in your farm… ADAM supports clustering via network load balancing.  If you have setup up NLB for SharePoint, it then should not be too difficult to set it up for ADAM as well.  This also eases configuration on Internet-facing servers… you don’t need to allow additional firewall rules from the SharePoint web server to an ADAM server in your trusted network.

• Place the DB external to the SharePoint server for scale out … you don’t want to install an essential component on a web farm server that you want to be able to take down to apply maintenance.

• I should be something short, and fairly memorable.  It also should sounds distinct from the Internal URL… I am trying “PartnerPoint.uvm.edu” to start out with .

Gotchas:

• ADAM Setup:

• ECTS requires SSL for ADAM… check the Event Viewer “ADAM” events for SSL errors.  Documentation suggests giving the ADAM service account rights to the required certificate in the “All Users” profile… this worked for me in TEST once my certificate has a Fully Qualified Domain Name in its subject line.  My auto-enrollment generated certs only have the FQDN in the SAN (subject alternative name) field, thus I needed to generate a new cert for SSL to work.  Once doing the PROD deployment, this fix did not work, and I had to copy the PROD SSL cert from the “Computer Account” Personal certificate store to the “Service Account” Personal certificate store (the store labeled “ECTS Instance”)
• In our production environment I had trouble running the setup script… this was because I was trying to use ports that ADAM considered “invalid”.  Keep an eye on %windir%debugadamsetup.log if scripts fail… as indicated here:
  http://technet2.microsoft.com/windowsserver/en/library/2080b841-2211-400f-b393-04675a1653651033.mspx?mfr=true

• It seems that host headers may be required by the setup scripts… if initial config fails, try adding host headers to internal and external web sites, then running setup again.
• Connection Strings are for ADAM and the ECTS database are stored in the web.config files of each SP web site instance… you can inspect these to validate your config.  Also, you can change the ECTS database using these connect strings.  By doing to I was able to rename the database to “ECTSTest” so that I will be able to install the PROD database on the same server.
• In more complex environments where you are adding ECTS to an existing SharePoint server, the ects_setup_sharepoint.vbs script may not update all of the web.config files on your server.  This was not a problem on my test server, but it was a real pain in production.  To fix the issue, I copied the following sections from my Extranet site web.config to by internal (”Default” zone) web site web.config:

<connectionStrings>
<add name=”ADAMConnectionString” connectionString=LDAP://myserver:636/CN=Users,OU=ECTS,dc=mycontext />
<add name=”DBConnectionString” connectionString=”Data Source=MYDB; Database=ECTS; Integrated Security=SSPI” />
</connectionStrings>
<location path=”_layouts/ExternalCollaboration/PasswordReset.aspx”>
<system.web>
<authorization>
<allow users=”*” />
</authorization>
</system.web>
</location>
<system.net>
<mailSettings>
<smtp from=PartnerAdmin@myserver>
<network host=”smtp.myzone.net” port=”25″ defaultCredentials=”true” />
</smtp>
</mailSettings>
</system.net>

Help Resources:

“SharePoint – Collaboration” forum on MSDN:
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=2012&SiteID=1

ECTS online documentation on TechNet:
http://technet.microsoft.com/en-us/library/cc268155.aspx

Here is one that really helped me:
(actually, the same information is available on many web sites, but this is really concise.  Getting “real” debug output helps to identify the source of config problem.  I found these stack traces a lot more useful than looking at SharePoint diagnostic logs)

http://www.sharepointblogs.com/michael/archive/2007/06/28/sharepoint-under-the-hood-see-real-error-description-and-callstack-stack-trace.aspx

Marius provide the following mapping info in his fine blog on MSDN:

Mapping:

Alert Severity – Its corresponding integer value

Critical – 2
Warning – 1
Information – 0

Alert Priority – Its corresponding integer value

High – 2
Medium – 1
Low – 0

Read more here:

http://blogs.msdn.com/mariussutara/archive/2007/12/17/alert-severity-and-priority-use-with-override.aspx

So remember, when downgrading an alert from "Critical" to "Warning", change in from "Severity 2" to "Severity 1".  "Severity 3" will just cause more paging… TWTTTTH!

PowerPoint 2007 version:

http://www.uvm.edu/~jgm/seminars/MM2008-CollaboratingWithSharePoint.pptx

PDF Version:

http://www.uvm.edu/~jgm/seminars/MM2008-CollaboratingWithSharePoint.pdf

I am going to assume that the use of any copyrighted content in this presentation falls under “fair use”, but IANAL, so send me that DMCA takedown notice if I am wrong…

http://www.petri.co.il/configure_tcp_ip_from_cmd.htm -and-

http://www.markwilson.co.uk/blog/2005/10/using-netsh-to-set-multiple-dns-server.htm

• To set your IP address:
  netsh interface ip set address name=”Local Area Connection” static <ip address> <netmask> <default gateway>
  (Note:  If you are using netsh on a platform earlier than Server 2008 (i.e. Server 2003) you may nned to provide more explicit parameters such as:
  netsh interface ip set address name”Local Area Connection” source=”static” addr=”<addr>” mask=”<mask>” gateway=”<gateway>” gwmetric=”1″)
• To set your first DNS server:
  netsh interface ip set dns “Local Area Connection” static <DNSServerIP>
  (NOTE:  You may want to set DNS info first if you need your interface to be functional as soon as the IP address comes online.)
• To set your first WINS server:
  netsh interface ip set wins “Local Area Connection” static <WINSServerIP>
• Setting up additional WINS and DNS servers:
  • run “netsh”
  • go to the context “interface ip”
  • run:
    add dns "Local Area Connection" <DNSServerIP> index=2
then
    add wins "Local Area Connection" <WINSServerIP> index=2
  • Verify settings with:
"ipconfig /all" or "netsh interface ip show config"

Installing VMWare Tools:

http://www.flickr.com/photos/jimboy/sets/72157602876493918

• In the ESX console, initiate “Install VMWare Tools”
• At the server console, switch to D:, run setup.exe with typical options, wait wait wait wait, affirm that you want to install the updated help files, reboot.

Changing the console resolution:

http://www.netometer.com/video/tutorials/core-server-change-resolution/index.php

• use regedit.exe
• navigate to:
  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlVideo{BBF118A6-4C44-4FE4-A8A3-965A9A577F98}000
  (or whichever GUID key have the subkey of “0000″ named “VolatileSettings”)
• Change “DefaultSettings.XResolution” and “DefaultSettings.YResolution” to your desired values in decimal format.

Enabling remote desktop:slmgr

http://www.petri.co.il/managing-windows-2008-server-core-rdp.htm

• cscript C:WindowsSystem32Scregedit.wsf /ar 0
• netsh advfirewall firewall set rule group=”Remote Desktop” new enable=yes

Activating a KMS:

• After networking is configured, use SLMGR.vbs to activate your KMS
• For you sanity, you may wish to perform “cscript //H:cscript” to set the command line script interpreter as the default script handler.
• run “slmgr.vbs -ipk <KMS product key>”
• run “slmgr.vbs -ato” to activate the KMS
• run “Netsh advfirewall firewall set rule group=“Key Management Server” new enable=yes” to allow KMS client traffic through the firewall (more on this below)
• run “slmgr.vbs -dlv” to monitor KMS activity.

Allowing Remote Administration:

http://blogs.technet.com/server_core/archive/2008/01/14/configuring-the-firewall-for-remote-management-of-a-workgroup-server-core-installation.aspx

• Netsh advfirewall firewall set rule group=“<rule group>” new enable=yes
• <rule group> can include:

• Remote Event Log Management
• Remote Service Management
• File and Printer Sharing
• Remote Scheduled Tasks Management
• Performance Logs and Alerts
• Remote Volume Management
• Windows Firewall Remote Management

The new Windows AIK v1.1 which supports Vista SP1 states that you must run the "postreflect.exe" tool on any offline Vista SP1 image before you attempt to apply that image to new hardware.  Why?  I don’t know… they have some mumbo jumbo about critical driver availability which is hard to grok.  The problem for me was that PostReflect failed to work! 

Here is what I did:

1. Applied Vista SP1 to a fresh Vista Enterprise install
2. Ran sysprep on the system, then used imagex from a WinPE instance to capture the image
3. transferred the image to our distribution server (which has Microsoft Deployment 4 and the new AIK installed).
4. Used imagex to mount the image in read/write mode
5. Ran "vsp1cln.exe" from the AIK to remove the SP1 uninstall information.
6. Ran "postreflect e:\mount\windows c:" to "reflect" the critical device drivers in the offline image mounted at "e:\mount", which uses the system drive letter "c:" when running.  This returned a "FAILED" error, with return code "0×0000007E".

What the heck?

Since SP1 and postreflect are brand new, Google and the Microsoft news groups were of no help in debugging the problem.  The godlike Mark Russinovich was.  I started "procmon.exe" with a filter for "postreflect.exe", then ran the prostreflect operation again.  As usual, I captured a ton of activity, but it not take too much examination to see that postreflect was looking for the AIK 1.0 DLL "drvstore.dll", but was unable to find it.  As a quick fix, I did a "cd" to "C:\Program Files\Windows AIK\Tools\x86\Servicing\6.0.6000.16386_x86" (where one copy of drvstore.dll is located).  I then re-ran postreflect, and the operation now completes successfully!

As a long-term fix, I copied the contents of "C:\Program Files\Windows AIK\Tools\x86\Servicing\6.0.6000.16386_x86" to a directory "C:\Program Files\Windows Imaging", then laid the contents of "C:\Program Files\Windows AIK\Tools\x86\Servicing" and "C:\Program Files\Windows AIK\Tools\x86" on top of that.  My "Windows Imaging" folder was already in my system "PATH" environment variable as a fix for a similar problem we had with "wdsutil" in the past.  "postrefect" now should be able to locate all of the files that it needs for future operations.  However, I will need to keep an eye out of future AIK tool updates… those files will need to be copied to my "Windows Imaging" folder.

Some digging revealed this forum post:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2003817&SiteID=1

It is suggeted here that the file “Fields.xml” in the directory “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\TSATypes” contains illegal curly-brace characters (i.e. {}).

To fix the problem, we mack a backup of fields.xml, then search and replace ID=”{ with ID=”, and }” with “. After performing these actions, stsadm is able to create an export archive of the site.

Another forum hints that one of the site templates in the “fab 40″ application templates is at fault, but I cannot determine which one this would be from the content of the files.

I had a look that the Vista setup log files on a system that was experiencing the reported error:
http://support.microsoft.com/kb/927521
To look at the log, press shift-F10 to bring up a command prompt, then “cd” to “C:\$WINDOWS.~BT\Sources\Panther”, and “notepad setuperr.log”.  In this case we see that the file “WinPEpge.sys” failed to copy owing to a “sharing violation”.

Some quick Googling reveals:
http://support.microsoft.com/kb/944817
Some of these images have a file called “WinPEpge.sys” in their root directories.  This file is not supposed to be in the image at all.  I have purged the Student X20 and X30 images of this foulness.  I am not sure how that file got in there, as it should be excluded by default.  However, to be safe I have updated the WDS Deployment and Capture images with config files that explicitly exempt the winpepge.sys file from capture and deployment.

Having to spend four hours on this today was not all bad, though.  This gave me the chance to add GImageX.exe to the deployment/capture images:
http://blogs.technet.com/deploymentguys/archive/2008/01/03/gimagex-is-back.aspx
this is a new graphical front-end to imagex that allows easier image capture, mounting, and maintenance.  It will be available on the CD drive letter of a WDS Capture/Discover ISO, or the flash drive letter of a USB bootable version.

I really should try to dredge though the current image library for these “winpepge.sys” files in some sort of programmatic fashion.  Doing so is made somewhat more complicated by the fact that you cannot directly edit WDS images that have been single-instanced into “.RWM” files by the WDSUTIL or its sister MMC console… ImageX just can’t handle this.  You have to export the image from WDS, then edit it, then re-import.  WDSUTIL is highly script-able, so this should be possible… it is just not “simple”.  Maybe next week…

Fortunately, not much scripting is required… FOR comes to the rescue again!

for /R .\ %i in (*.inf) do peimg /inf=”%i” e:\winpe_x86\mount\Windows

In this case, we are using “/R” to tell “FOR” that we want it to recurse though the given directory path (in this example, “.\”) setting the variable “%i” to be equal to each “inf” file that it finds.  On each pass we run “peimg /inf=”, injecting our variable as the inf file to inject.

All of this assumes that you have already mounted the target WIM file into the directory e:\winpe_x86\mount\Windows.

We could fairly easily automate the whole winpe build process by stringing together these commands:

1. imagex /mountrw <WIM file> <WIM Index> <mount directory>
2. for /R .\net %i in (*.inf) do peimg /inf=”%i” <mountDirectory>\windows
3. for /R .\hdc %i in (*.inf) do peimg /inf=”%i” <mountDirectory>\windows
4. for /R .\system %i in (*.inf) do peimg /inf=”%i” <mountDirectory>\windows
5. for /R .\SCSIAdapter %i in (*.inf) do peimg /inf=”%i” <mountDirectory>\windows
6. imagex /unmount /commit <mountDirectory>

We could then use WDSUtil to import the image into a Windows DS server, convert it to a “discover” image.  OSCDIMG from the Windows AIK to create automatically a WDS Discover ISO file.

After much head banging, I discovered this KB:
http://support.microsoft.com/kb/254632/en-us

The reason I have been having so much trouble is that the Microsoft domain-rooted CA will use either the issuing certificate template validity period (which is what I would expect) or the maximum CA cert validity period defined in the CertSvc registry key, whichever is less (which is not what I expected at all).

After setting the registry values in the KB on my Enterprise Root CA, I now have a SubCA that has a five year validity.  Huzzah!

Here is what did not work:

Creating a new Subordinate CA Certificate with a five year validity period…
This failed because the existing CA uses for renewal the template that issued it’s certificate initially.  Thus, if I remove the default “SubCA” template from the list of certificate templates to issue, cert renewal fails claiming that there is no appropriate template available.  I can’t seem to add the default SubCA template to the “superceded templates” list, either.  It is likely that this is a hard-coded limitation; perhaps MS does not want us altering the default CA templates?  Whatever… at least I get a bit more time on my certs now, thankfully.

1. Stop services on your iSCSI initiator host that may be writing to your lun to be migrated.
2. Refresh your target lun from source using snapmirror:
   snapmirror update <target>
3. Break your snapmirror relationship to prevent further writes to the new production lun:
   snapmirror break <target>
4. edit /etc/snapmirror.conf, remove the entry for your broken snapmirror target.
5. stop any remaining services on source server that rely on iSCSI storage
6. stop iSCSI initiator service
7. Upgrade MS iSCSI initiator to current version (at this time, v2.0.5
8. Unmap your original lun on the source filer:
   lun unmap <source lun>
   (NOTE: “lun show -m” can be useful for displaying existing map relationships)
9. Map your new lun to an iSCSI initiator group that contains your host:
   Map lun map <target lun> <target iSCSI group>
   (NOTE:  You can use igroup create -i -t windows <iSCSI group> and igroup add <initiator ID> <iSCSI group> to define the “iGroup” used in this command.  The initiator ID can be read from the poperties of the MS iSCSI Initiator Control panel.)
10. start the iSCSI service
11. log in to the new iSCSI targer, bind lun
12. restart services

Pre-migration:

1. Verify destination filer settings:
   1. Quota configuration – compare /etc/quotas to current config on “files”.
   2. CIFS config:
      1. /etc/cifsconfig_shares.cfg
      2. /etc/cifsconfig_setup.cfg
      3. /etc/cifs_homedir.cfg
   3. Filer options:
      capture output from “options” command and compare settings to source filer. – DONE!
   4. DNS and WINS registration settings

Migration:

1. Disable CIFS on the source filer:
   cifs terminate -t 0
2. Force final SnapMirror synchronization:
   1. snapmirror update coffee:vol1
   2. snapmirror update coffee:vol2
   3. snapmirror update coffee:vol3
      (Note:  the “-w flag can be used if we want to wait for a mirror operation to complete before returning control to the console)
3. Break snapmirror relationship:
   1. snapmirror break coffee:vol1
   2. snapmirror break coffee:vol2
   3. snapmirror break coffee:vol3
   4. update /etc/snapmirror.conf, remove old relationship definitions.
4. Initialize quotas on target filer:
   1. quota on vol1
   2. quota on vol2
   3. quota on vol3
5. Rename the source filer

1. cf disable the cluster.
2. Verify SPNs for “files” computer account.
3. delete “files” computer account
4. assign new IP address to the filer, reboot
5. run cifs setup on source filer
   1. read config using rdfile /etc/hosts
   2. Assign new IP using ifconfig vif1-720 132.198.102.???
   3. ping to/from an external host to verify the update
   4. verify /etc/hosts and /etc/rc, then reboot to verify IP change
   5. update settings in options autosupport to reflect host name changes.
   6. Verify or force registrations in /etc/hosts, WINS, DNS.  May need to manually register DNS using “nsupdate” on cdc01.
6. reboot to verify CIFS config files
7. Check settings in /etc/nsswitch.conf
8. cf enable  the cluster
9. reset filer login info in dfm:

1. dfm host set <hostname> hostlogin=<username>
2. dfm host set <hostname> hostpassword=<password>

Post-migration testing:

1. Home directory connections via CIFS (Windows 2000/XP/Mac)
   Verify all variations on homedir mounting still function:

   1. \\files\NetID
   2. \\files\~
   3. \\files\cifs.homedir
2. Home directory connection via SFTP/WebDAV
3. Kerberos authentication from CAMPUS and “uvm.edu” k5 realm
4. NTLM authentication levels/packet signing
5. Quota enforcement
6. Cluster failover
7. DFM monitoring (need to update passwords used by DFM for connection to filers)
8. Autosupport info in NOW.NETAPP.COM.
9. NDMP backup from Networker.

http://www.uvm.edu/~jgm/wordpress/?p=96

Today, I used this procedure as a jumping off point for discovering all servers using high-order RPC ports, and the RPC end-point mapper. I followed the procedure above to discover all available hosts in a subnet. Next we use the excellent SysInternals tool “PSExec” to gather “netstat” information on this list of hosts. Here is the command:

for /f %c in (availablehosts.txt) do echo %c >> epmsys2.txt && psexec.exe \\%c -e netstat -ano | find “135″ >> epmsys2.txt

Taking it apart…

• Start a “for” loop for each server listed in the “available hosts” file.
• Start each pass though the loop by “echoing” the host name, and appending the output to a capture file.
• Next, use PSEXec to execute “netstat” on each host. Use “-e” to reduce resources used on the target host (does not load user environment remotely).
• Pipe netstat output though “find”. Filter for port 135 (the DCE RPC Endpoint Mapper).
• Direct output from psexec/netstat to the same file.

I ran this command two times… once for TCP Port 135, and then again for TCP port 6150 (which is the first “high order” RPC port available on our servers). The result is a file content like this:

WINUPDATE.campus.ad.uvm.edu
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 692
printers.campus.ad.uvm.edu
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 692
TCP 132.198.102.14:135 132.198.92.189:2917 TIME_WAIT 0
TCP 132.198.102.14:135 132.198.92.189:2918 TIME_WAIT 0
TCP 132.198.102.14:135 132.198.92.189:2919 TIME_WAIT 0
TCP 132.198.102.14:135 132.198.92.189:2920 TIME_WAIT 0

Every server listens with the EPM, but only a few have active connections. These are the ones that are actually using the service. As we expected, the Domain Controllers have many active EPM connections. What I did not expect is that the print server is also very busy… I wonder why?

My last attempt as using NLB ran into some troubles… NLB-fronted Server 2003 terminal servers were pokey at best.  This time, I thought I should look at the implications of running Microsoft NLB on ESX server, which is the platform I am using for the TS Gateways.

Unsurprisingly, I learned some new things…

• Microsoft NLB is not supported by VMWare:
  http://pubs.vmware.com/vi301/mscs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=mscs&file=mscs_intro.3.4.html
  (Configuration assistance is available only for “Microsoft Cluster Services” (MSCS)).
• When using NLB on ESX, it is recommended that you use “multicast” mode.  This is mentioned several places:

• http://pubs.vmware.com/vi301/server_config/wwhelp/wwhimpl/common/html/wwhelp.htm?context=server_config&file=sc_adv_netwk.6.5.html
  Here, it is noted that if you are using NLB in Unicast mode, you will need to disable the NIC failover “notify switches” flag on your ESX VSwitch.  This is uindesirable because it will increase the switch convergence time in the event of a failover (since the switches will have to rebuild their lookup tables following connection failures).
• http://pubs.vmware.com/esx254/admin/wwhelp/wwhimpl/common/html/wwhelp.htm?context=admin&file=esx25admin_cluster.11.13.html
  This document outlines the procedure for setting up NLB on Windows 2000/ESX Server 2.5.  Here you are specifically instructed to use Multicast mode.  No reason is given.
• http://pubs.vmware.com/vi301/server_config/wwhelp/wwhimpl/common/html/wwhelp.htm?context=server_config&file=sc_security_cfgnet.15.13.html
  In this document, procedures for securing ESX server switch ports are outlined.  It is recommended that you prevent the ability of an OS to change the MAC address of its adapter (specifically, to prevent network adapter impersonation that could be used in an attack).  NLB multicast mode does not need to alter the NICs MAC address, and this is compatible with this hardening procedure

If a client (Windows Server 2008, Vista, or really just about any recent-vintage Linux distro) is configured to use IPv6 by default, and it is fortunate enough to find an IPv6 address registered in DNS for a server to which it is attempting to connect, guess which protocol it will use to connect to the server?  But what if your router can’t pass IPv6 traffic?  If you happed to be using a Vista client, it appears that after a few seconds, we fall back on IPv4.  However, my Server 2008 RC0 clients are timing out and failing to connect to each other.  Bummer!

Rather than going though the impossible process of fixing IPv6 on campus, I have decided to kill IPv6 on my Server 2008 systems.  Here is where I got my information:

http://www.microsoft.com/technet/community/columns/cableguy/cg0506.mspx

The instructions are for Vista, but they work on Server 2008, too.  I just set this registry DWORD:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents

to Hexidecimal 0xFF, thus disabling all IPv6 on the server.  A quick reboot forced the server to re-register all DNS entries, thus making IPv6 go away.  Voila, we are back in business (and RDP connections to my new servers from Vista clients are working much more smoothly).

I believe the solution is to add a “Subject Alternative Name” (SAN) to the SSL cert.  Unfortunately, IIS does not make this easy.  The certificate request wizard does not allow for the specification of a SAN.  Once again, it is the command line to the rescue…

The following KB details use of the certreq.exe command line tool to generate a certificate signing request with SAN, suitable for submission to a third-party CA:

http://support.microsoft.com/kb/931351/en-us

The instructions worked fairly well for me, except that I needed to change the “RequestType” to “PKCS10″ from “CMC”, as shown here:

http://www.microsoft.com/technet/prodtechnol/office/livecomm/library/confcerts/lcscon_9.mspx

So, here is a representation of my certreq.exe .inf file:

[Version]

Signature=”$Windows NT$

[NewRequest]
Subject = “CN=[FQDN of Server],OU=Enterprise Technology Services,O=University of Vermont,L=Burlington,ST=Vermont,C=US”
Exportable = FALSE
KeyLength = 1024   
KeySpec = 1             ; Key Exchange
KeyUsage = 0xA0     ; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
RequestType = PKCS10

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
[RequestAttributes]
CertificateTemplate = WebServer
SAN=”dns=[FQDN from CN]&dns=[Original FQDN of Server]“

Note the syntax of the “SAN” line.  Be sure to use “dns=” twice… once for each FQDN.

New generate the certificate request file:

certreq.exe -new cerreq.inf certreq.req

Cut and paste the contents of your .req file into the application for your third-party CA cert.

Today I used:

http://certs.ipsca.com/srvc/Buy.asp

Look!  Free certificates for “.edu” (higher education, and the like) customers!  Certificate generation is a bit slow, but then what do you expect for free?  I wonder what will happen when their root certificate expires in 2009?

Here is what I came up with… it is not the work of a networking genius, but it worked:

Tools required:

• GnuWin32 “cut.exe” defined in your %PATH%, GnuWin32 XARGS (optional)
• Remote registry rights on all systems to be queried
• A windows CMD console, ’cause I am lame and can’t take the time to learn PowerShell.

The process:

First, we want to discover all of the servers in a network range that have valid registered DNS names:

FOR /L %d in ([starting octet],1,254) DO nslookup [network].%d | find “Name:” | cut.exe -c 10-100 >> networkhosts.txt

This command will use the FOR command to run “nslookup” on the IP address “[network].%D” several times, starting with [starting octet], incrementing by one, then terminating at “254″.  The output of the lookup is sent to the windows (not GnuWin32) “find” command, which will locate the output line containing “Name:” (this will be the actual DNS name of the system).  The output line is trimmed of all information except the DNS name using “cut” (DNS names start at the 10th character of the NSLookup output). Output is sent to a file for later use. 

Next we test to see if the discovered host names are available.  By doing so, we prevent wasting time on operations against servers that are not available:

FOR /F %d in (networkhosts.txt) do ping -n 1 %d && echo %d >> availablehosts.txt

We use FOR again to ping all of the host in the file that we create above.  If the ping succeeds (meaning the host is there),  repeat the host name with an “echo”, and send that output to a file. 

Now we actually need to see if the hosts have any publicly available network shares… One approach would be use the the old-school “net view” command to display visible shares on the remote hosts:

FOR /F %S in (avaiablehosts.txt) DO net view \\%S >> VizShares.txt

This is useful, although it will not disclose “hidden shares”.  To get around the “hidden” shares problem, we can perform a remote registry query to see all shares (other than the defaults) which are made available at the startup of the “server” service.  These shares are published in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares
We will use “reg.exe” and another FOR loop to see what hidden shares exist:

FOR /F %H in (availablehosts.txt) DO echo %H >> hiddenhosts.txt & reg query \\%H\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares /v /f *$ | find “$” | cut.exe -d$ -f1 >> hiddenhosts.txt

We start this loop with an ECHO command so that we can insert the name of the host being investigated into our output file.  The /v flag in REG.exe returns only values under the selected key, and /f *$ filters the output to lines containing only share names ending in “$” (in other words, hidden shares).  Output is passed though “find” to filter out all but the lines that have the actual share name in them.  Output is then sent through ”cut” to trim everything but the actual share name from output, and then send the trimmed output to our final file for human analysis.

An industrious admin would chain these commands in a single task.  However, I wanted to check each output file for validity before proceeding… we have some old DNS entries that were making trouble with the remote registry commands.  If I had not removed them, the script could have taken many hours to complete.  If you want to do this, the GnuWin32 tool “xargs” will be invaluable, as it will allow you to pass standard output into commands that do not support standard input, such as “net view”, and “reg.exe”.  For example, we could nest the second “FOR” loop above into the first, and then pipe the output to XARGS NET VIEW”

| Xargs.exe net view

Fortunately, we are not bound my the same laws of etiquette in the IT world.  When your VM Guest cops and attitude with you, you can kill it.  Unfortunately, VMWare does not document all of the ways in which you can put an end to pestilential guests.  Fortunately, we have a Platinum support contract, and I was thus able to learn how to send a proper kill signal to a guest.  Here is the drill:

• Verify that ESX “thinks” your guest is still running:
  • vmware-cmd "<pathToVmxFile>/<vmxfile>.vmx" getstate
  • Should return:
    getstate() = on
• Scan the running VM Guest process names to find the VM “World ID” of the hung guest:
  • cat /proc/vmware/vm/*/names
  • Output returned should be similar to this:
    vmid=1105 pid=-1 cfgFile="/vmfs/volumes/46f13af6-27b2dd91-6873-00145e6d4c2c/hyperion11/hyperion11.vmx" uuid="50 26 41 af 30 dd cb 48-2d 9a ed 48 6e 6d db 6c" displayName="hyperion11"
  • Take note of the “vmid” above (in this case, “1105″.  This is the vmid of the “world”, or “cartel” of you guest OS.
• Send a “kill signal 9″ to the discovered world ID:
  • /usr/lib/vmware/bin/vmkload_app -k 9 <vmid>
  • Output should be similar to this:
    08 09:40:43.189: Sending signal '9' to world 1104.
• Verify that the guest is not running:
  • vmware-cmd "<pathToVmxFile>/<vmxfile>.vmx" getstate
  • Returns:
    getstate() = off
• You should then be able to start the guest normally.

A few months ago we had a consultant on site to set up services on two new Windows Server 2003 hosts.  It was another one of those fun “n-tier J2EE” things.  DNS names were requested for “hyperion10.uvm.edu” and “hyperion11.uvm.edu”.  However, since the hyperion hosts were connected to our  ”campus.ad.uvm.edu” domain, their “internal” names were appended with the “campus.ad.uvm.edu” suffix.  Thus, these servers thought of themselves as “hyperion1x.campus.ad.uvm.edu”, even though there was no legitimate DNS entry for these names. 

For most services, this is not a problem.  However, we discovered that some hyperion services advertise themselves using this internal computer name, rather than a name chosen by the application administrator.  To work around the issue, we requested manual DNS entries be generated for “hyperion10.campus.ad.uvm.edu” and “hyperion11.campus.ad.uvm.edu”.  Unfortunately, the decision was made to change the hyperion hosts internal computer name DNS suffixes instead of waiting for the new DNS entries.  This solved his problem and did not create any immediate issues, so he moved on.  Months later, this decision would make the OpsMgr admin very unhappy.

Here is what broke… the Hyperion systems now tried to update the “DNS Suffix” attributes of their computer objects in Active Directory.  By default, Server 2003 AD performs “validation” on DNS suffix registrations, and disallows names that are not in the AD forest.  Thus, the DNS suffix change was denied in AD, and a event was logged in the System event log:

Source: NETLOGON
Event ID: 5789
Description:  Attempt to update DNS Host Name of the computer object in Active Directory failed.  The updated value was ‘HYPERION10.uvm.edu’.  The following error occured:
The parameter is incorrect.

This is pretty innocuous, and went unnoted.  However, the mismatch of the computer’s perceived FQDN and its registered FQDN in AD completely broke Kerberos authentication on this system.  Because AD did not know of a host called “hyperion10.uvm.edu”, it never generated a Kerberos SPN (Service Principal Name) for this host.  A legitimate SPN is required for Kerberos auth to function.  NTLM authentication still worked, so no one noticed the problem again. 

Two months ago, we installed an Operations Manager 2007 server.  All of our managed servers took their agents without complaint, except for the blasted Hyperion servers.  Since these systems were on the opposite side of a firewall, we naturally blamed the firewall and spent a lot of time performing “Wireshark” packet captures, looking at “netstat” output, and running “procmon” on the management server.  

The breakthrough finally came yesterday when I had a look at the Operations manager event logs on the hyperion servers (which were running the OpsMgr agents).   The following error was found in the log several times:

Source: OpsMgr Connector
Event ID: 21016
Description:  OpsMgr was unable to set up a secure channel to <fqdn of RMS> and there are no failover hosts…

I did some poking at news.microsoft.com in the operations manager groups.  I searched for threads with “agent” and ”monitored” (as in the “not monitored” status of the agents in the console).  There I found the suggestion that Kerberos problems can prevent secure communications between OpsMgr agents and the RMS.  There was a suggestion that Kerberos loggin be enabled to rule this out as a problem.  Thus, I added the following reg values to the Hyperion servers:

Key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value: REG_DWORD LogLevel
Data: 1

A reboot was necessary to activate logging.  Soon we had the culprit captured in the system log:

Source: Kerberos
Event ID: 3
Description:  A Kerberos Error Message was recieved:
on logon session
…
Error Code: 0×7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Server Realm: CAMPUS.AD.UVM.EDU
Server Name: host/hyperion10.uvm.edu

Ah!  No principal existed for hyperion10.uvm.edu!  And thus, the OpsMgr agent could not create a secure channel with the server using Kerberos, which is the only method implemented in OpsMgr without resorting to certificate-based authentication.

Now that I knew what the problem really was, fixing the problem was easier (although not easy).  The following KB contained info on fixing DNS mismatches between the host and Active Directory:
http://support.microsoft.com/kb/258503

There, we are instructed to add the required Service Principal Name directly to Active Directory.  This was pretty easy… we just need the Windows Server 2003 Resource Kit Tools, and then we run:

setspn -a host/hyperion10.uvm.edu hyperion10

We also needed to fix the mismatch in DNS suffixes.  The KB above suggests removing the requirement for client computer DNS suffix validation throughout the entire domain.  This sounded like a bad idea to me, so I did some investigating, and found that you can modify the ACL a computer object in Active Directory to allow the “SELF” object to have “Write DNS Host Name Attributes” rights under the “Properties” tab in the AD Users and Computers MMC (also, there is “Write dNSHostName”… probably the same thing).  I added this right, then rebooted the servers.  The Event IDs discussed above all went away!  Start the party!  Pop the cork!  A quick agent re-install and our bloody Hyperion systems are now being monitored.

I am not sure what the moral of the story is… always grant your consultants rights to your DNS server?  Watch your consultants like a hawk 24×7?  Don’t bother with system monitoring as it is a time sink?  Always take a nap under your desk at lunch time?  Feel free to draw your own conclusions…

The script shown here allows you to create a persistent snapshot of a Windows Server 2003 volume, and then expose it as a drive letter. This opens up all sorts of other scripting possibilities. Most immediately, it allows me synchronize filesystems from a point-in-time copy on demand on in a scheduled task. I need this for replication of Windows deployment points, and for refreshing our pre-prod ApplicationXtender server from the production environment.

This script uses “VSHADOW.exe”, part of the VSS SDK available here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=0B4F56E4-0CCC-4626-826A-ED2C4C95C871&displaylang=en

VSHADOW cannot expose existing “client accessible” shapshots that were generated by standard Volume Shadow Sopy Service scheduled tasks, but you can use this script to schedule your own snaps. VSHADOW can even create a snap, execute arbitrary code (such as “robocopy”), and then delete the snap immediately (using “non-persistent snapshots).

Cool!

Here is the blow-by-blow:

• Retract radEditor Lite (global scope version)

• stsadm -o retractsolution -name radeditormoss.wsp

• You will find one ONET.XML per site-template.  This file is located in the <Template>\Xml\ subdirectory of “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates”
• In the <WebFeatures> section of each ONET.xml, add the following:

<!– radEditor MOSS Feature –>
<Feature ID=”747755CD-D060-4663-961C-9B0CC43724E9″ />
<!– radEditor MOSS IE Feature –>
<Feature ID=”F374A3CA-F4A7-11DB-827C-8DD056D89593″ />

• See my previous post on Taking control of SharePoint

• From “CMD”, run:
  stsadm -o enumsites -url [SharePointWebAppURL] > [enumsitesXMLfile]
• The UNIX utility “CUT” will be used to trim out all XML code from the output file.  Sadly, there appears to be a bug in “CUT when executed from within CMD that prevents further standard output redirection or pipelining, so we now switch to a UNIX shell (cygwin “bash”, or the UnxUtils SH.exe):
  cat [enumsitesXMLfile] | cut -f2 -d\” -s > [enumsitesTXTfile]
  unix2dos [enumsitesTXTfile]
  (We are “cutting” after the first text delimiter (or “field 2″) using the quotation mark as the delimiter.  Note that the quote character (”) needs to be escaped (\). Use of UNIX2DOS will convert the UNIX-style output file to Windows semantics.)

• FOR /f %s IN ([enumsitesTXTfile]) DO stsadm -o enumsubwebs -url “%s” | find “<Subweb>” > [subwebXMLfile]
• In BASH:
  cat [subwebXMLfile] | cut -c11- | cut -f1 -d\< > [subwebTXTfile]
  unix2dos [subwebTXTfile]
  (Here we use “cut” to trim after the 11th character in the source file, and then agan after the first “\” character.)
• Consolidate sites and subwebs into single control file
• type [subwebTXTfile] > [masterTXTSiteList]
• type [enumsitesTXTfile] >> [masterTXTSiteList]
• Using GnuWin32 “sort” command:
  sort -du [masterTXTSiteList] > [masterSortedTXTSiteList]

• FOR /F %s IN ([masterSortedTXTSiteList]) DO stsadm -o activatefeature -name radEditorFeature -url “%s” & stsadm -o activatefeature -name radEditorFeatureIE -url “%s”

From:

Become Administrator of the Entire Web Application – The SharePoint Farmer’s Almanac

To grant a user or group administrator access to a given web application do as follows.

1. Go to SharePoint Central Administration.
2. Click on the Application Management tab.
3. Under Application Security click on Policy for Web Application
4. Click Add Users
5. Confirm your settings on the screen (defaults should be what you want) and click Next
6. Now enter your user or group of users
7. Click the box beside Full Control ? Has full control.
8. Click Finish

Weyland.be » Disable System Beep in Windows Vista

In Spring 2007 we introduced you to two new tools in the Windows Deployment arsenal at UVM.  Further work on and refinement of these tools continues.  If you are interested in developing for, deploying with, or training on these tools, please contact Greg Mackinnon in the ETS Systems Architecture and Administration department.

A second quick overview on these new technologies follows:

Windows DS:

With the release of Windows Vista, Microsoft replaced their venerable “Remote Installation Service” (RIS) with an entirely new product: “Windows Deployment Services” (or Windows DS).  You can learn more about Windows DS here:
http://www.microsoft.com/windowsserver/longhorn/deployment/services.mspx
RIS has been in use at UVM since 2003.  This year, Back-to-School systems will be deployed using Windows DS rather than RIS. 

At the present time, we have installed the Windows DS software on our central imaging servers, SYSIMG1 and SYSIMG2.  We have converted all legacy Windows XP RIS images into the new “Windows Image Format” (WIM) used in Windows DS, and made these images available on the servers.  Use of RIS will be phased out sometime this year.

“LiteTouch” Deployment:

To complement the Windows DS service, Microsoft also has released a major update to their Business Desktop Deployment (BDD) toolkit.  This toolkit includes the wonderfully handy “LiteTouch” deployment system.

LiteTouch is an unattended OS deployment tool.  Unlike the image-based technologies “RIS” and “WIndows DS”, LiteTouch performs a full OS install.  When deploying via LiteTouch, you start the target computer using special boot media (USB flash drive, CD-Rom, or NetBoot), answer a few questions about how you would like your system configured (choose your OS, applications, and configure domain-joining options), and then let LiteTouch do the rest.  When done, you will have a fully-patched OS with most or all of the drivers and applications necessary to get your job done already installed.

LiteTouch has the potential to replace RIS and Windows DS for most system deployments on campus.  In the future, we most probably use image-based tools  for bulk-deployments only (i.e. for back-to-school distribution and lab deployments).  LiteTouch also has the potential to accelerate the image-development process; in fact, all of this year’s back-to-school images were generated using the LiteTouch system as a starting point!

Many places on campus can start using Windows DS and LiteTouch deployment tools simply by “net booting” their computers.  However, network boot can be slow and is not available to everyone.  As an alternative, you can create a bootable CD or USB flash drive to access the servers.  Directions are available on the Campus domain file server:
\\files.uvm.edu\software\Windows_Deployment_Services

New Software:

• WinSCP / PuTTY:
  The venerable “SSH Communications Security” SSH/SFTP client provided on Depot systems in the past has not received an update since 2004.  As a replacement we will be using “WinSCP” (a graphical SFTP/FTP/SCP file transfer client) and “PuTTY” (a simple SSH console program).  Both are well-regarded, active Open Source applications.
• Pidgin:
  Pidgin is the free, Open Source instant messaging program formerly known as “GAIM”.  It replaces the commercial instant messaging program “AIM”, and has the advantage of being spyware and adware free.
• UVM Wallpaper Pack 2007:
  Our first annual (?) wallpaper pack is included on all new systems.  This is a collection of 20 regular and wide-screen formatted images from around the UVM campus.  These images are integrated into the “Desktop Background” control panel on Vista.
• AVG AntiVirus:
  Owing to several significant bugs in the Symantec AntiVirus software used in the past, new student systems will ship with “AVG AntiVirus Free Edition”.  This is a temporary arrangement while replacement AntiVirus package is identified.  Because of restrictions on “corporate” use, this software will not be made available at the UVM Software Archive, and its use on University-owned systems is prohibited.

Removed Software:

In the interest of maintaining leaner, more stable base systems, the following applications will not be included on new computers:

• AOL Instant Messenger (AIM)
• Apple iTunes/QuickTime (not supported on Vista at the time of image development)
• DivX Codec
• Oracle Calendar (Still available on Faculty/Staff systems)
• Nullsoft Winamp (No longer maintained
• RealPlayer
• SSH Communications Security SSH

We again use:
STSADM -o enumsites to collect all existing site URLs. We cleverly strip out the site URLs from the (I hate) XML output. We then save these URLs to a text file (one URL per line) and use this to feed a FOR loop on the CMD shell.

Use:
STSADM -o activatefeature -id 747755CD-D060-4663-961C-9B0CC43724E9 -url [site URL]
To activate the RadEditor for SharePoint lists for a given site (initially this will activate the tool for Mozilla users only).
Then use:
STSADM -o activatefeature -id F374A3CA-F4A7-11DB-827C-8DD056D89593 -url [site URL]
To activate the RadEditor for IE users.

Where did we get those ID strings you ask? Look in the “Feature.xml” file in the following locations:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\RadEditorFeature
and
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\RadEditorFeatureIE

The feature ID is listed in this document between the (big surprise) Id tags.

Now, how to I activate this feature so that it will be on for all future sites? Perhaps the answer is “Feature Stapling”:
http://blogs.msdn.com/cjohnson/archive/2006/11/01/feature-stapling-in-wss-v3.aspx

If you have not seen RadEditor before, you need to:
http://www.telerik.com/products/sharepoint/radeditor.aspx

I did run into a brief hiccup in installation, though. After installing the software and deploying it as a solution from SharePoint central admin, I found that regular users could not activate the RadEditor feature on their sites. We get the intimidating “403 Forbidden” error…

After a good deal of head pounding, it is SysInternals to the rescue again:
http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx
I loaded up ProcMon, set a filter for the SharePoint service accounts, and another filter for Result = “ACCESS DENIED”. Lo and behold, the WSS service account is getting “ACCESS DENIED” to the following files:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES\RadEditorList.ascx
and
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\RadEditorFeature\RadEditorList.ascx

Interestingly, the WSS service account actually does have R/W access to these files. However, recall that the WSS service account actually impersonates the credentials of the user currently logged in to SharePoint. We note in the ProcMon event details the following:
Desired Access: Generic Write, Read Attributes
Disposition: OverwriteIf
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File
Attributes: A
ShareMode: Read, Write
AllocationSize: 0
Impersonating: CAMPUS\[UserID]

Eureka! The SharePoint end user needs to be able to over-write these files! Sounds a bit shaky from a security perspective, but if we grant the R/W access to these files to all SharePoint users, we find that problems with site feature activation disappear.

Read all about our BDD infrastructure, LiteTouch system, Application installation scripts, and OS patching methodology here:
https://sharepoint.uvm.edu/sites/ad/distribution/

Apparently this service is called during deployment of a VM Guest from a template, and is not needed after deployment:
http://www.vmware.com/community/thread.jspa?threadID=6007&messageID=39465

Ass I had to do was run:

c:\WINDOWS\vmware_imc\bootrun -unregserver

Oracle doc on installing OCal:
http://download-east.oracle.com/docs/cd/B25553_01/install.1012/b25463/clientinstallation.htm#CHDEJIIB
Here is how I did it:

1. run “cal_win_1012.exe /A” to extract the contents of the install shield application
2. copy the unison.ini file from a properly configured client’s Application Data directory. Strip out the user-specific lines. Paste it over the unison.ini in the install directory.
3. install silently using msiexec /i "Oracle Calendar.msi" /qb (or use the /qn switch for a fully silent install)

Here is my working UNISON.INI:
[GENPREFS]
offlineab=true
[WEBLINK]
mode=off
[CONNECTIONS]
Conn_00_Type=offline
Conn_00_Name=Offline
default=1
Conn_01_Type=normal
Conn_01_Name=UVM Calendar
Conn_01_Desc=
Conn_01_Serv=calendar.uvm.edu
Conn_01_MNCapability=FALSE
Conn_01_ConfiguredForNode=FALSE
Conn_01_Nodes=10000,CIT
Conn_01_Node=10000
Conn_01_Auth_00_Short=cs-basic
Conn_01_Auth_00_Long=CST Basic Authentication
Conn_01_Auth_00_NeedsItem=TRUE
Conn_01_Auth_00_ChangePassword=TRUE
Conn_01_Auth_01_Short=cs-standard
Conn_01_Auth_01_Long=Standard Authentication
Conn_01_Auth_01_NeedsItem=TRUE
Conn_01_Auth_01_ChangePassword=TRUE
Conn_01_NumAuths=2
Conn_01_Auth=cs-standard
Conn_01_Comp_00_Short=cs-simple
Conn_01_Comp_00_Long=Run Length Encoding Compression
Conn_01_Comp_01_Short=none
Conn_01_Comp_01_Long=None
Conn_01_NumComps=2
Conn_01_Comp=cs-simple
Conn_01_Encr_00_Short=cs-acipher1
Conn_01_Encr_00_Long=Affine Cipher
Conn_01_Encr_01_Short=cs-light
Conn_01_Encr_01_Long=Light Encryption
Conn_01_Encr_02_Short=none
Conn_01_Encr_02_Long=None
Conn_01_NumEncrs=3
Conn_01_Encr=cs-acipher1
numConnections=2
enableSingleSignIn=FALSE


Enter DISKPART, WinPE, and VMWare. We now can create fake OEM partitions on virtual machines, and redeploy on demand without disrupting anyone’s routine.

Here is the procedure:

• Boot VM Guest to WinPE ISO file (you can use a WDS Discover image)
• When WinPE is loaded (with or without WDS discovery client), press SHIFT-F10
• At the command prompt, type diskpart, then follow this script:

• select disk 0
• clean
• create partition primary id=DE size=78 (Partition ID “DE” is a Dell OEM partition. DISKPART will hide it for you automatically.)
• select partition 1
• format fs=fat quick
• To verify your partition, enter display partition

Ultimately, the support engineers concluded that the site had experienced some corruption of security profiles. They were hesitant to use their internal tool for purging security profiles from the site for fear that this would create other problems. Ultimately, they recommended using stsadm -o export with the -includeusersecurity flag to create a backup of the site. (”Export” is different from “Backup” in that it does not create a full backup of the site… it just backs up the content.) We then use “import” to restore the backup file to a new, blank site. Using this process, new security profiles are created but site content stays the same.

Here is the full procedure for rebuilding a site using stsadm:

• change the site owner to match the login ID of a user with sharepoint infrastructure admin rights.
• stsadm -o export -url http://sharepoint.uvm.edu/sites/[sitename] -filename [backupfilename] -includeusersecurity
• verify that the export file appears to contain all of the site data. It may be a good idea to use stsadm -o backup to create a secondary backup as well.
• stsadm -o deletesite -url http://sharepoint.uvm.edu/sites/[sitename]
• stsadm -o createsite -url http://sharepoint.uvm.edu/sites/[sitename] -ownerlogin [loginID] -owneremail [email address]
• stsadm -o import -url http://sharepoint.uvm.edu/sites/[sitename] -filename [backupfile] -includeusersecurity
• Login to the site, verify content. You may want to revert the site owner to the original user ID at this time.

Threadmaster can be downloaded here:
http://threadmaster.tripod.com/
Config is easy… run the small CMD file to install the Threadmaster service, then use REGEDIT to tune the product. All settings are in HKLM:\SYSTEM\CurrentControlSet\Services\ThreadMaster\Parameters. Set a default per-thread CPU threshold, and add applications that you want to have different rules to the “Applications” subkey.

Anyway, what this really is about is gaining access to top-level Sharepoint sites when you have been locked out. This never was a problem for us in the past as our “Farm Administrators” had access to all sites. However, it appears that security changes in WSS v3 have blocked this access. Now, when people send me a note asking for assistance with their site, I often am greeted with a friendly “access denied” message.

If the site administrator is unable to add me to the ACLs for the site, I need to take ownership to get anything done. It took me awhile to sort this out as documentation on WSS v3 is still a bit sketchy.

Here is how you take control from the command line:
stsadm -o siteowner -url https://sharepoint.uvm.edu/sites/[sitename] -ownerlogin [DOMAIN\netID]
ALternatively, you can use the -secondarylogin switch to take ownership of the “Secondary site administrator” role.

1. Implemented Mandatory Profiles on the Terminal Servers, using GPO.
• Installed Hotfix to enable the use of a single profile for all users on a TS via GPO:
  http://support.microsoft.com/kb/908011
• Created a Mandatory Roaming Profile following instructions on how to do this for an XP client:
  http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_profile_roaming.mspx?mfr=true
  I copied this profile to C:\Documents and Settings\MANDATORY on one TS, then changed the ACLs to allow Read/Execute ONLY for "Authenticated Users", and used "Robocopy" to replicate this profile WITH PERMISSIONS to the neighboring TS.
• We then edit the GPO for the terminal server as follows:
• Computer Policy->Administrative Templates->Windows Components->Terminal Services->Set Path for Roaming TS Profiles:
  "Profile Path" = "C:\Documents and Settings\MANDATORY"
  "Do not append the user name to the profile path" = "TRUE"
2. Delete all existing local user profiles on all terminal servers
3. Note that this gets us one step closer to implementing "Flex Profiles":
   http://www.brianmadden.com/content/content.asp?ID=551
   There actually are lots of web resources on implementing "Flex Profiles" or "Hybrid Profiles", which essentiall combine the speed of Mandatory profiles with the benefits of roaming/local profiles.  I am not going to implement this at this time, as it seems more trouble than benefit.
4. Implemented Fallback Printer Drivers, as previously linked here:
   http://www.brianmadden.com/content/content.asp?ID=438
• Used settings recommended in above article – "HP DeskJet 550C" for PCL printers and "HP Color LaserJet 5/5M PS" for PS printers.  This seems to generate satisfactory results.  I also tested using "HP LaserJet 4", "HP LaserJet 4000 Series", and "HP Color LaserJet" with no better/worse results.
• Installed HP Universal Printer Driver v3.0.0 for PCL 5, PCL 6, and PS.  Tried using this as the fallback driver with disasterous results (crashed the print spooler… yuck!).  I have kept these drivers installed for use with the wtsuprn.inf mappings file, or if people want to print manually to the installed Universal Printer instances.
5. Installed PDFCreator on both TS systems.  This gives users a fallback option to print to PDF and redirect the output to their local drive via the RDP client.  This should be useful for more sophisticated users.
6. Implemented wtsuprn.inf printer mappings file, with entries copied over from the existing "Hercules" MetaFrame server.
7. Grudgingly installed a driver set for the Canon iR (imageRunner) printers.  I only did this because the drivers were WHQL qualified, and insisted that we do some testing to verify that the drivers were not destabilizing the servers.  I do not recommend that we get in the habit of installing third-party drivers on demand, but we do have a lot of these imageRunners on campus, and this driver set should help out.

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.

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 NETWORK\Admin 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:\Software\Legato\DiskXtender\RPC\DxCli2\”
      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%\XtenderSolutions\Content Management\Render Server\WxRender.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.

Associating an icon with PDF files in a Sharepoint library:
http://www.sharepointblogs.com/ssa/archive/2006/10/13/13812.aspx

• 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:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_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 Files\Common Files\Microsoft Shared\web server extensions\12\BIN>” 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 campus\sa_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:
    • Sharepoint -> https://sharepoint.uvm.edu
    • Extranet-sharepoint -> https://sharepoint.uvm.edu
    • Works from off-campus?
  • 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

As everyone now knows, Vista has officially launched. We don’t expect to see Vista shipping on new Dell systems until sometime in January, but that is really just around the corner. Vista has dozens of significant new features and hundreds of smaller changes that will affect the ways that we deploy, configure, and support Windows at UVM. Now is the time to get ready for Vista! The Enterprise Technology Services department has convened a new committee of the IT Standards group to ramp up IT staff at UVM for Vista support.

This article will present an overview of many of the policy decision points, technology infrastructure implementation hurdles, and workstation security changes that will need to be made before we can realistically claim to support Vista at UVM. Each section will contain an introduction to a key Vista technology, and will be followed by questions concerning its deployment and support. Each section will conclude with links to external documentation whenever possible.

Please consider how you can assist in this gargantuan effort. The Vista support committee will be happy to accept your help with any of these tasks.

The Vista support committee will continue to make information available to the UVM community though a few channels. Email discussion will occur on the IT-Standards mailing list:
http://list.uvm.edu/archives/it-standards.html
Major announcements will be posted to IT-Announce:
http://list.uvm.edu/archives/it-announce.html
Notes from the IT Standards Vista task force can be found in the semi-official “UVM Wiki”:
https://wiki.uvm.edu/index.php?title=Windows_Vista
Additional Vista work notes pertaining to support of Vista in the CAMPUS Active Directory domain can be found in the “Active Directory at UVM” Sharepoint site:
http://sharepoint.uvm.edu/sites/ad/

Vista product editions:

Many people have been bewildered by the impressive array of Vista product editions. The prospect of supporting many separate Vistas has many IT support staff concerned. However, in practice we really will need concern ourselves only with four of the eight editions: Home Basic, Home Premium, and Enterprise, and Ultimate.

Both varieties of the “Home” editions lack corporate management features, and thus will not be deployed or supported on institutionally-owned systems.

“Business” edition is the baseline managed Vista product, and it will be the default edition sold on business-class computers at retail stores. However, Business edition will likely be a fringe product at UVM owing to the availability of the “Enterprise” edition. Enterprise edition is available to Volume License customers (such as ourselves), and it includes the drive encryption feature known as “BitLocker”.

“Ultimate” edition contains all of the features of all other editions, plus some multimedia tools not available elsewhere. This is not likely to be seen much at UVM except perhaps in media labs, or on high-end workstations used by individuals with specialized multi-media needs.

Thus it seems that “Home” editions will be fairly typical for student systems, while the vast majority of faculty/staff computers will run “Enterprise” edition. However, we will need to verify the actual availability of the Enterprise product for Campus Agreement customers. At this time, we still have not obtained access to all Vista products, so the seeming clarity of this decision may be called into question in a few weeks.

A matrix of Vista product editions and their various features can be found at Paul Thurrott’s excellent “SuperSite for Windows”:
http://www.winsupersite.com/showcase/winvista_editions_final.asp

User Account Control (UAC):

Under default conditions, new Vista deployments prompt the user to create a new user account with Administrator privileges. A common criticism of Windows security has been that any user session running with Administrator-level privileges decreases the effective security of the system – a malware attack can take advantage of the rights of the current user to take complete control of the computer.

However, a new feature of Vista known as User Account Control (UAC) can mitigate this vulnerability. UAC forces administrative users to “sign-off” on any action that would require administrative access before that action occurs on the system. This prompting occurs in a “Secure Desktop” environment that clearly delineates prompt from other running tasks.

In a default installation, the user is given a simple Allow/Deny prompt any time an action taken on the system requires administrative privilege… even if the current user is an administrator. This mode of operations is called “admin approval mode”. Alternatively, admin approval mode can be configured to force the user to enter his credentials for each administrative action (either in the form of a password, or an alternative authentication mechanism such as Smart Card for biometric scan).

UAC also can be configured to allow non-privileged users an opportunity to enter the credentials of a privileged user when administrator rights are required. This UAC mode of operation is called “Over-the-Shoulder Authentication”. This functionality is similar to that of the familiar “run as” command originally introduced in Windows 2000, but it is more transparent to the end-user.

Microsoft recommends that organizations restrict their users to run in standard (or non-privileged) mode, and refrain from sharing any administrative credentials with the user. Although this seems sensible from a security perspective, this approach may not be workable from a support perspective. If central IT does not take responsibility for the ongoing maintenance of software on end-user workstations, preventing staff from making administrator-level modifications to the computer can severely hamper user productivity.

Unsolicited opinion alert… Microsoft put a lot of consideration into UAC. Considerable user feedback on UAC was gathered and analyzed during the Vista beta program. Microsoft used this feedback to refine the UAC defaults to their present state. I think that in absence of a managed systems initiative at UVM, we should use the UAC defaults for new Vista deployments. Although this does mean that most users will continue to run as administrator, UAC still forces users to effectively run as standard users, and we should see corresponding improvements in session security. Forcing departmental users to run as standard users without access to administrator credentials will put a strain on IT support staff for which they are not prepared. And If we distribute a local Administrator password to the client, we really will see no improvement in system security over the default. If we keep UAC running in default admin-approval mode, we also gain the freedom to disable the default “Administrator” account, this gaining some additional security from scripted attacks on that account.

Given the broad impact of the UAC feature, it is unsurprisingly that Microsoft has made a mountain of UAC information available. Below are some links that may be useful.
Technet has a good overview of UAC technology:
http://www.microsoft.com/technet/windowsvista/security/uac.mspx
TechNet provides this article which may be of assistance to anyone attempting to understand the changes in Vista which affect users running in standard mode:

http://www.microsoft.com/technet/technetmag/issues/2006/11/UAC/default.aspx

Finally, the team at Microsoft which develops UAS has their own blog, which is loaded with useful links on specific UAC topics:

http://blogs.msdn.com/uac/

Driver Installation Control

Should we choose to restrict some or all users to run as “standard users”, we will need to be prepared for frequent support calls to assist in the installation of supplemental system drivers and software. On Vista Enterprise and Ultimate editions there is a supplemental feature of UAC which may mitigate some of these calls. By using this “Driver Installation Control” feature, the installation of drivers from a “trusted store” can be delegated to standard users. Also, whole classes of drivers (such as printers and removable media) can be flagged for installation by non-administrative users.
 

More research needs to be conducted into the feasibility of this delegation feature. Is the pool of hardware that our clients utilize predictable enough to make the implementation of a useful trusted driver store possible? Also, if we delegate the ability to install whole classes of drivers to standard users, are we effectively crippling the security of the standard user session?

Unfortunately, comprehensive documentation on this feature is hard to come by. A basic overview of Driver Installation Control is available in the TechNet article previously referenced above:

http://www.microsoft.com/technet/technetmag/issues/2006/11/UAC/default.aspx

Hopefully, additional documentation will become available in the near future.

ActiveX Installer Service

Another supplemental feature of UAC makes it possible to delegate installation of ActiveX controls from “approved sites” to standard users. This functaionality is made possible though the “ActiveX Installer Service”. If we restrict many users to standard mode, we might want to consider maintaining a well-maintained list of common ActiveX controls (such as Adobe Flash and Adobe Reader) to reduce the frequency of requests for Over-the-Shoulder credential requests.

As with the “Driver Installation Control” feature discussed above, research needs to be conducted into the practicality of this feature. Maintenance of the trusted controls list will require dedication of central IT resources to the task.

The UAC team blog has made this information available on the ActiveX Installer Service:
http://blogs.msdn.com/uac/archive/2006/09/13/752248.aspx
Unfortunately, as with the Driver Installation Control service discussed above, more technical information of the ActiveX Installer Service is hard to come by at this time.

BitLocker Volume Encryption

BitLocker is a whole-volume encryption technology available in Vista Enterprise and Ultimate editions. When activated, BitLocker will encrypt all of the contents of the system volume on a single Vista install. By contrast, the Encrypting File System (EFS) which is available on Windows 2000 and XP encrypts only selected files and folders on an XP installation, but not the NTFS file system itself. BitLocker effectively renders a hard unless it is loaded on its native workstation. This feature could be extremely valuable in ensuring regulatory compliance (HIPPA, FERPA, etc.), and also could help to reduce the dangers caused by the loss or theft of institutionally-owned computers.

A full discussion of the technology behind BitLocker is out of the scope of this article. Links are provided at the end of this section for those who want to learn more about the hocus-pocus that makes BitLocker possible.

In its most basic mode, BitLocker checks OS file integrity and then allows any user to boot the operating system. A BitLocker-protected system will not load if it has been removed from its native hardware, or if its boot files have been modified. This level of protection is helpful, but an unauthorized user still could access data on the drive if they have physical access to the entire workstation (i.e. if the BitLocker-protected laptop computer is stolen, rather than just its hard drive). In order to properly protect the encrypted drive data, you must add supplemental protection either by requiring input of a PIN number or presence of a USB key at boot time. These supplemental protections make loading the OS a two-factor process. You must possess both the BitLocker-protected computer and its USB decryption device or you must have knowledge of the decryption PIN.

Note that BitLocker only protects the operating system volume. Additional volumes cannot be encrypted by BitLocker, and so use of either EFS or a third-party encryption program will be required if there is a need to store sensitive data on multiple partitions.

Before we can recommend or support BitLocker in the enterprise, we need to answer the following questions:

• Will BitLocker impose enough of a performance penalty on older systems that we do not want to restrict its use to current-generation systems?
• Will the hardware requirements of BitLocker makes its use impossible on legacy computers?
• What is the recovery model for lost volume encryption keys? If a user loses his BitLocker USB key, his system will become unusable. A Key Escrow will be required to permit system recovery in these instances. According to BitLocker documentation, this Escrow is integrated into the product, but we will want to test the recovery process in several scenarios to ensure supportability.
• Given that BitLocker only protects the system volume and not the entire hard drive, is this an adequate technology? Most client systems deployed at UVM have only a single partition, so this product limitation is of no consequence. However, we will want to make sure that this will not be a problem for a significant portion of our clients, and have workarounds available of any staff who need them.

A fair high-level overview of the technology from Wikipedia:
http://en.wikipedia.org/wiki/BitLocker_Drive_Encryption

A more in-depth presentation is available on Microsoft TechNet:
http://www.microsoft.com/technet/windowsvista/security/bittech.mspx

A step-by-step implementation also is available on TechNet:
http://www.microsoft.com/technet/windowsvista/library/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx

Volume Licensing and Product Activation

With Windows XP, Microsoft introduced the anti-piracy program known as “Windows Product Activation”. To the great relief of system administrators everywhere, Volume License customers were not required to perform product activation. With Vista, this has changed. UVM will be required to activate all institutionally-owned installs of Vista from a central pool of activations. Microsoft has made two methods of Vista product activation available to volume customers: Multiple Activation Keys (MAK) and the Key Management Service (KMS). Most organizations will need to use a combination of these methods. It appears that we will want to use both methods as UVM as well.

MAK activation is similar to the product activation methodology used in retail versions of XP. The only difference is that the product key entered to allow activation can be used on more than one system. MAK activation has the advantage of being one-time and permanent (you only need to key in the MAK into the Vista client once during the lifetime of the OS). If we use MAK activation, we will need to closely guard our keys from casual distribution. Any leak of our keys could cause rapid depletion of remaining available activations and a good deal of hassle in reactivating invalidated products. Microsoft recommends that we never publically disclose the MAK to end-users, and has made a variety of tools available to allow organizations to remotely activate managed systems. We do not yet have access to these tools, and will need time to test them before they can be implemented in production.

If we choose to use KMS activation, we will need to install redundant KMS servers on campus and secure them. Because KMS is designed to be a lightweight, easy-to-use service, it will activate any volume-licensed Vista client on the KMS network. The advantage of KMS is that it requires intervention neither from the Vista client nor from the KMS administrator to function. KMS activations are non-perpetual and will expire if a Vista client fails to check in for a six-month period. This has the advantage of allowing the organization to reclaim activations for systems that have left our management jurisdiction without intervention from Microsoft. It has the disadvantage that the KMS service is non-discriminatory; recall that KMS will activate any non-activated Vista client, even non-authorized privately-owned systems. Thus, we will need to design a mechanism external to the KMS to limit access to the service to only those clients who are entitled to it. We are just at the starting stages of planning this service, and do not have any coherent thoughts on how we might accomplish these service restrictions at this time.

Vista Volume Activation Step-by-Step Guide:
http://www.microsoft.com/technet/windowsvista/plan/volact1.mspx
Vista Volume Activation FAQ:
http://www.microsoft.com/technet/windowsvista/plan/faq.mspx
Webcast on Volume Activation in Higher Education environments:
http://sharepoint.uvm.edu/sites/ad/Vista%20support%20documentation/Vista_Activation.wmv

IPv6

All editions of Vista ship with the IPv6 protocol activated by default. Microsoft engineers want to make sure that Vista users will be prepared for an IPv6-based Internet if and when IPv4 starts to get phased out. Although the presence of the IPv6 stack should not create any real issues for end users, it will create some additional load on campus DNS servers, and may slow network access in some unusual circumstances. Thus, we might want to consider deactivating IPv6 on the primary network interface of systems deployed at the University.

Application Compatibility Testing

Fundamental changes in the architecture of Windows Vista make application compatibility a much greater problem than it was with Windows XP. Many line-of-business applications used at UVM are not yet supported on Vista. Until all supported applications are validated on Vista, central IT support of the operating system will be limited.

ETS staff are maintaining a matrix of supported Windows software at UVM on the Sharepoint Active Directory site:
https://sharepoint.uvm.edu/sites/ad/Lists/Vista/AllItems.aspx
We will endeavor to keep this list up-to-date with application updates as they become available.

Image development

Vista has shipped with an impressive Business Desktop Deployment (BDD) guide, which includes a powerful Automated Installation Kit (AIK). One of the promises of these tools is the reduction of the number of images that need to be maintained by IT staff. This is an exciting prospect as ETS maintains a library of over 80 Windows XP system images at present. With this many images available, true image maintenance never really occurs.

Many questions need to be answered before ETS will be ready to perform customized installations of Vista. The remainder of this section will enumerate some of these questions, and some factors to be considered when answering them.

• Can additional MS (i.e. Office 2007) and third-party (i.e. Antivirus, VPN) products be added as components in the Windows System Image Manager (SIM)? If not, are these easy ways to automate the installation of additional software onto systems in the post-imaging process (i.e. using product installation command lines in the Unattended.XML file used by the Vista setup program)?
• How will we handle domain-joined vs. non-domain joined systems during image deployment? The new network deployment tool known as Windows Deployment Services (WDS) automatically creates domain computer accounts at system installation time. However, student systems are not joined to our CAMPUS domain, so this computer account never will be used. It’s presence in the Active Directory domain creates a management problem.
• How will we handle deployment of systems which are not entitled to use of our Vista Volume License media (i.e. Student-owned systems)? Can use easily deploy images based on Dell OEM media? Should we eschew imaging in favor of a scripted installation of after-market software followed by a “reseal” operation? Without answers to these questions, we will be blocked from re-imaging any student systems that are covered under a Volume License (i.e. all systems other than those maintained by the Business School).
• What software should be part of the standard configuration? Is this software currently Vista-compatible?
• How will we maintain security patches on managed systems? Our current patch management system for domain-joined computers (Windows Server Update Service, or WSUS) will not provide updates for Vista. To maintain Vista systems we will need to upgrade to WSUSv3, which currently is available only in beta. Another consideration is the need to provide updated drivers to Vista users. Although the array of out-of-box drivers included in Vista is impressive, users of older hardware will need supplemental drivers immediately after installation. Synchronizing these drivers into the WSUSv3 system will present an administrative challenge that we need to think through.

The Windows AIK contains extensive documentation on these topics, and is freely available for download at the Microsoft download site:
http://www.microsoft.com/downloads/details.aspx?FamilyID=c7d4bc6d-15f3-4284-9123-679830d629f2&DisplayLang=en
A more lightweight download is the Windows AIK users guide for Vista, RC1. Note that this is the pre-release documentation, and that it may contain differenced from the RTM documentation contained in the full AIK download:
http://www.microsoft.com/downloads/details.aspx?FamilyID=993c567d-f12c-4676-917f-05d9de73ada4&DisplayLang=en

Group Policy for Vista

With the release of a new operating system, we need to deploy new operating systems management tools. As we have previously mentioned, Vista has dozens of significant new features, many of which may need to be managed in our various Active Directory domains.

Fortunately, Microsoft already has released Vista Group Policy extensions (ADMX) which, after being imported into a Windows 2003 Active Directory infrastructure, will allow very granular management of Vista features. But as will all Group Policy changes, we will need to do extensive testing of all proposed management settings. Improper configuration of Group policy can result in the effective crippling of all systems in a domain.

A spreadsheet of ADMX Group Policy setting is available from the Microsoft download site:
http://www.microsoft.com/downloads/details.aspx?FamilyID=41dc179b-3328-4350-ade1-c0d9289f09ef&DisplayLang=en
Also, a Step-by-Step guide to the deployment of ADMX-based Group Policy setting can be found here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=311f4be8-9983-4ab0-9685-f1bfec1e7d62&DisplayLang=en

With these most useful links:
http://www.brainsys.be/default.asp?pg=15
A kernel-level lockdown tool for Terminal Servers
http://threadmaster.tripod.com/
A tool for throttling application threads on a TS.
http://go.microsoft.com/?linkid=2606126
Microsoft Print Driver redirection tool. Too COOL!

The Blog also contained these articles on Server 2003 "fallback printer mappings": http://www.brianmadden.com/content/content.asp?ID=316 http://www.brianmadden.com/content/content.asp?ID=438

The app has many external dependencies which I am trying to get functioning on the new TS boxes.

First challenge – MIT Kerberos for Windows.
Tricks here were:

• Install a current KFW version… old Citrix server has v2.1.1, but this will not run on Server 2003. Current release is 3.0.0, which works fine
• but I needed to make sure that an appropriately configured krb5.ini was available in the application install directory, and that the same file was removed from %windir% directory.
• Also, we needed the Kerberos app directory in the system PATH (which it is done by the installer, but requires logout/login to take effect).

Next challenge:
Oracle client for Windows
We did the usual massive download of the latest Oracle client (450+ Mb), then did a runtime install. I needed to copy the TNSNAMES.ORA from the old server to the NETWORK\ADMIN folder in the new oracle home. ALSO, since this is a terminal server, I needed to recursively add the local “users” group to have R/X rights to the Oracle home, and I needed to grant users of the Casey app rights to “Create Global Objects” in the local security policy.
NOTE: Currently I have a copy of tnsnames.ora in the application directory for every app that needs it… I reinstalled the Oracle client in “instant” mode… this install does not set an oracle home, so the client does not know where to search for tns information. I need to set a home globally, then move the tnsnames.ora file out to the home…

MOM 2003

• http://support.microsoft.com/?id=917615

Dell IT Assistant

• http://www.dell.com/downloads/global/solutions/remote_sql_server_ita7.pdf

Firewall changes:
In moving the servers, we had to assign new IP addresses in our protected 102.0 subnet. Thus, I had to research the firewall exceptions required for access to the servers. It seems the two required ports are:
TCP port 2967 (Inboud) – for Symantec AntiVirus service (RtVscan.exe), for AV definition push updates, and client monitoring
UDP port 38293 (Inbound) – for Intel PDS service (pds.exe), allows retrieval of AV policy settings
(initial rules were not correct, resulting in clients falling out of the mangement cycle)

LiveUpdate changes:
I have been wanting to change the address of our internal LiveUpdate server for awhile… we are now using http://liveupdate.uvm.edu as the primary distribution server, with http://norton1.uvm.edu, http://norton2.uvm.edu, and http://liveupdate.symantecliveupdate.com as backups. “liveupdate.uvm.edu” is a round-robin record that alternates between norton1 and norton2. We are considering a load balancing implementation instead, but this probably is unnecessary given the presence of “backup servers” in the liveupdate.hst file distributed to clients.
The only real problem here was that many of the file types in the LiveUpdate download directory were not of recognized “MIME Types” (i.e. they were not html, xml, zip, txt, audio/video, or MS Office files). I had to add the following extensions to the IIS configs before clients could successfully retrieve updates:
.x00, .ieg, .m25, .ia64ap, .x86, .lin
Once these MIME types were added and I had run an “iisreset”, LiveUpdate started to function normally.

Reporting Services
Migration of reporting services is a total PIA. I am trying to migrate the back-end database to an external SQL 2005 server from SQL 2000 in addition to re-installing the Reporting Services binaries on the new Norton2 server. Here are the steps taken so far:

• detach the SymReport database from the old server, copy the files to the new server and attach
• change ownership of the database back to its original setting
• change the compatibility level of the database to “9.0″ (SQL 2005)
• install the new SQL native client on the SAV hosts
• launch the Reporting services installer setup.exe. Note: do not launch from the autorun setup menu on the SAV CD! You must use the reporting services setup.exe or the advanced install options that we need will not be available.
• supply the credentials necessary to connect to the new SQL 2005 DB. Also, specify alternative credentials for the db user, datasource name, and db name. Use the DB name that was imported into the SQL 2005 server, and get the username that was previously used from the DB security tabs.
• After install, the reporting server should smoothly reconnect to the existing DB. You can check that this is happening in the SQL activity monitor pane.

Unfortunately, ran into some problems with the Reporting Agent on the primary SAV server (it is running a remote agent). The agent slowly hogs up all the memory on the box and is creating a CPU-bound condition (very bad news on an ESX host). I has no success trying to troubleshoot the situation, and I was not having fun… Using sysinternal tools I was able to watch the ReportingAgentLauncher thrash the heck out of some temp files that it was creating, but it never did anything with these files. I believe there must have been some bad configuration information being fed to the SAV server from the reporting database, and that this was creating a loop. So untimately I fixed the situation with the following “solution”:

• Uninstall reporting services
• Reinstall with a new database (thus abandoning old report data)

Voila… reporting services are running normall, we have our first production SQL 2005 database, and our second set of production ESX guests.

Our blades are equiped with 2x dual core AMD Opteron processors, two Qlogic FC HBAs, two Broadcom 57xx Ethernet ports, and 8Gb of RAM. We thusly are using Server 2003 64-bit edition for the install.

Server install and setup:

• Installed OS from the BladeCenter Management Module, mounting Server 2003 ISO file from a neighboring blade’s web browser. It is slow and ugly, but works.
• On first boot, we have no functioning network or FC HBA. I downloaded the latest Broadcom application ISO from IBM, mounted via managment module, and ran the installer. Also ran the “Broadcom Advanced Services” installer, then configured an Active/Active NIC team with VLANs for public networking (720) and the cluster heartbeat (4000).
• On the heartbeat network, we disable File and Print services, as well as Client for Microsoft Networks. Be sure to disable NetBIOS over TCP as well. LAN speed duplex does not appear to be configurable with this driver, but the switch ports have been set to negotiate for 1Gbps speed only, and PortFast is on to reduce port blocking time on initial NIC connect.
• Once networking is functional, I am able to transfer Qlogic HBA drivers to the server, and install them in the Device Manager control panel.
• We also transfer the DS4000 Storage Manager for Windows installer to the server (obtained from IBM.com), and then perform a client install of the software (this installs the RDAC multi-path I/O driver onto the server).
• Configure LUNs on the DS4800 storage server, configure LUN masking, and configure Zoning on the Brocade switches. SAN volumes are now available on the server.

Cluster Configuration:

• Setup Microsoft Distributed Transaction Coordinator as a cluster resource as well. Strictly follow instructions in MS KB301600. Created 1Gb lun for this task – drive letter “T”
• Setup a cluster group for MSSQL server, add physical disk resources for MDF and LDF files (database and transaction logs) (Drives M: and L:)

SQL Setup:

• Ensure that you are logged on to only one node of the cluster – setup will fail if there are active RDP sessions on both cluster nodes.
• From http://support.microsoft.com/?kbid=916760, create “Servers” and “Tools” directories for CD1 and CD2 contents, respectively.
• Run SQL Setup from the primary node in the cluster, source files extracted to our primary file server using the base path \\\software\sql2005server.
  
• Start with an installation of Workstation Components only… need to run this install on each node separately
• Run SP1 patch on both nodes to update SQL Setup Support files.
• Install all remaining SQL components (Database, Analysis services, Reporting, Notification, Integration). Select option to create failover cluster for Database and Analysis services, select drive M: as the destination for data files.
• Configure service accounts for every service
• Set server to “mixed” authentication mode for support of some of our apps
• Keep default collation settings (this uses SQL Collations for the Database service and Windows Collations (Latin_CS_AS) for Analysis Services).
• NOTE:Reporting Services will have to be configured after SQL install
• enabled automatic error reporting but NOT usage statistics.

Next Steps:

• http://msdn2.microsoft.com/en-us/library/ms171338.aspx – Review use of clustering with Notification Services
• Review Reporting Services deployment options:
  • Separate Reporting Services Instance for each application that uses it?
  • Central Reporting Services web cluster? (Would require 2x additional Windows 2003 EE installs!)

Good IBM Redbook on VI 3 and Director 5.10:
http://www.redbooks.ibm.com/redbooks/SG247190/wwhelp/wwhimpl/java/html/wwhelp.htm

More official guide to using ESX 2.5 with Director:
ftp://ftp.software.ibm.com/pc/pccbbs/pc_servers_pdf/managingvmware.pdf

Several management methods are available for ESX hosts. The Redbook focuses on using the Director Agent for Linux. The apparent reason for this are:

• Support for hardware alerting though the agent is becomming available with ESX3. This was not the case with ESX2.5, so the agent did not do much for you.
• “Level 0″ agents are managed though SSH. Under ESX 3, root login is not allowed via SSH, The linux agent relies on root access, so this agentless management method no longer works.
• SNMP is the only other management method, and who wants to go there?

I am developing a Vista compatability matrix for UVM-supported applications. Hopefully others will pitch in on this effort in the not too distant future:
Vista – The Road to Production Software Matrix

I expedite loading of the “WDS Discover” boot image (this is the image that allows loading of WDS server images) I decided to try creating a bootable “WDS Discover” image on UFD. The Vista Beta 2 BDD (and included AIK) include instructions on generating WinPE-bootable UFDs. However, there are two problems:

• The instructions do not work… the resuling UFD is not bootable!
• The image generated results only in a standard WinPE environment, not a WDS deployment GUI

Here are the missing bits fo informaiton:
When formatting a UFD for WinPE, you must set the formatted partition as “active”. To do this, plug your UFD into a Vista OS:
diskpart
select disk 1
select partition 1
format fs=ntfs override quick
active
assign
Failing to make the UFD partition “active” will result in an unbootable UFD. Note that the Vista build 5472 AIK includes these updated instructions.

In order to make a UFD-bootable WDS Discover image, you need to use the “WDSUtil” CLI (with /new-discoverimage or /new-captureimage options) or WDS MMC GUI.
Here are the steps:

1. Use ImageX to extract the Windows Vista SETUP image from the boot.wim that ships with the Vista DVD (e.g. “imagex /apply [path to boot.wim>] 2 [path to apply image]“)
2. Apply custom drivers (e.g. “peimg /inf: [path to driver] [path to applied image "windows" directory]“)
3. Capture the custom image (e.g. “imagex /boot /compress maximum /capture [path to applied image] [wim file name] [image name]“)
4. Import the image into WDS using the GUI or CLI
5. Use WDSUtil with /new-CaptureImage or /new-DiscoverImage and /Image:[image Name] to create a new capture or discovery image based on the custom WIM generated above.

You can now write your image to CD (using “oscdimg”) or to UFD (using the BDD/AIK instructions).

NOTE! If you expect to be able to capture using the WDS Capture image, you must first run “sysprep” on the OS in question. The WDS Image Capture Wizard will not work without sysprep!

It is full of tedious and laborious steps to manually repair the performance counter object mappings. Towards the bottom of the article, we learn that on Server 2003, the following console command will restore corrupted counters, thus obviating the need for any manual config steps:
LODCTR /R

This will re-read all of the perfXXX.ini files in the system32 directory and rebuild the counter data. If you have any apps running that do not house their .ini files in “system32″ you will need to load those manually.

In any event, the above command fixed the problem on SYSIMG1 quite nicely. Thanks, MS!

Here were the key steps, as outlined in this TechNet Article:
http://technet2.microsoft.com/WindowsServer/en/library/96969653-bd0f-44d7-af4f-f95c3016d2be1033.mspx?mfr=true”

• In the “flat” image for the platform to be imaged (in our case, the flat “Tablet PC 2005″ image) create a $OEM$ directory with a “textmode” subdirectory.
• Copy the SATA storage driver into the textmode folder. Make sure that the entry in the [disk] section of the TXTSETUP.OEM file in this directory does not contain a “relative path” on the end of entry. (i.e. the line should end with a simple “\”).
• Copy the exact text of the driver name from the [scsi] section into the [MassStorageDrivers] section of the Flat image’s i386\templates\ntstndrd.sif file. Also add the following lines:
  #Added this
  OemPnPDriversPath=”\\%SERVERNAME%\RemInst\%INSTALLPATH%\$OEM$\textmode”;\Drivers\Nic
  DUDisable=no
  DriverSigningPolicy=ignore

  [MassStorageDrivers]
  "Intel(R) 82801GBM SATA AHCI Controller (Mobile ICH7M)"="OEM"

• Also in the [unattended] section, set the OemPreinstall option to “yes”

Some interesting things that we discovered in making this work:

1. PNP NIC drivers that are accessed during the initial NDIS driver load can be added to ANY flat image on the server. A Tablet PC will access drivers from the “XP SP2″ Flat image. If you have more than one version of the same driver in different folders, only the first alphabetically listed driver will be made avaialble to RIS net boot clients.
2. Text-mode setup drivers (which generally are mass storage drivers) are loaded when setup.exe starts in earnest, after the NIC load process. These drivers must be available in the $OEM$ directory of the platform for which you are loading an image (RIPrep or Flat). If you are loading an RIPrep image for a Tablet PC, you must have appropriate drivers available in the Tablet PC flat image.

However, I seem to be having problems getting a PXE boot client in my office to load. PXE boot works, and the WIM image gets loaded onto the workstation. However, I get a “unable to communicate with the WDS server” error after the GUI loads.

Some Ethereal packet captures show that the client is sending a port map request to the server, and the server is telling the client to connect to port “5040″. This value is not in our range of pre-allocated RPC ports, so I assumed that this port is hard-coded into the WDS service.

Sure enough, a quick registry search reveals that this is a parameter of the WDSServer service:
\\HKLM\Software\System\CurrentControlSet\Services\WDSServer\Parameters\RpcPort
The default value was “5040″. I changed it to be within our range of excepted RPC ports, then ran:
net stop WDSServer
net start WDSServer

Lo and behold, I can now boot to WDS and install Vista. Cool. Now they just need to get the bugs out and give us the RTM WIM files. We will be ready!

Note: Net booting the install WIM is kinda pokey. I think I will try making a bootable USB drive next. I think this might be our best option for mass distribution.

-Geoff Duke,
in written communication to a Dell support “engineer”

• The installer for WSS 3 refuses to run claiming that I need Workflow Foundation v2.2 installed and ASP.NET 2.0 enabled on my site. Workflow foundation can be downloaded from www.microsoft.com/downloads. The ASP.NET issue was a bit more puzzling, since I throught I already had .NET 2.0 installed on the test server. A quick investigation revealed that it was installed, but not configured for or activated in IIS. I just ran the .NET framework installer again and now the installer runs.
• all of the pre-release documentation and the current “readme” file are available at http://www.microsoft.com/downloads. Irritating that they did not come with the beta 2 download… I had to hunt them down.
• After install, configuration failed. I had to run the “prescan” tool manually. The report that was generated showed that two sites were “broken”. Interestingly, I could not find any evidence that these sites actially exist when using either “stsadm -o enumsites” or the “Sharepoint Explorer” utility. Some googling revealed the concept of “site oprhans”:
  http://blogs.msdn.com/krichie/archive/2005/10/25/484889.aspx
  It is claimed that there is a tool available to fix this:
  http://support.microsoft.com/kb/918743/
  But as luck would have it our MS Essential Support has lapsed and Procuremetn has not processed the service renewal request. Dang! I will just fix the problem manually on the test server, but we will need that hotfix for Prod! Manual fix entails removing the content database from the virtual server, then adding it back in. This forces the Config database to remove all current entries, then recreate them.
• next problem is vexing… I get this error during the upgrade process:
  An exception of type System.Runtime.InteropServices.COMException was thrown. Additional exception information: The Indexer property in the MSSConfiguration table is not set to the name of this machine.
  System.Runtime.InteropServices.COMException (0xC0041229): The Indexer property in the MSSConfiguration table is not set to the name of this machine.
  I just can’t figure this one yet. Google is worthless.

Here are the steps that I have followed to build a new ISO, usable in VMWare Server Beta and VMWare Workstation 5.5…

1. Install the BDD 3.0 pack
2. from c:\program files\bdd vista\waik, install the WAIK using “startcd.exe”.
3. Using the included CHM files, follow the “Walkthough: Create a bootable Windows PE RAM Disk on CD-ROM”:
   1. from c:\program files\windows aik\tools\petools, run:
      copype x86 c:\winpe_x86
   2. step 2 in this procedure claims that you can copy EXE files (such as ImageX.exe) to c:\winpe_x86\iso, and they will then be included in the image…
      NOTE: These files show up on the “D:” drive after booting into WinPE. The reason for putting additional tools here is to reduce the memory footprint of WinPE. Everything in the X: drive is loaded into RAM at boot time!
      
   3. before actually making the iso, apply some customizations:
      1. Mount the WinPE WIM file:
         imagex /apply c:\winpe_x86\winpe.wim 1 c:\winpe_x86\mount
      2. Install drivers:
         peimg /inf=c:\drivers\vmware\vmxnet\win2k\vmware-nic.inf c:\winpe_x86\mount\Windows
C:\winpe_x86_2>peimg /inf=c:\drivers\vmware\vmxnet\win2k\vmxnet.inf c:\winpe_x86\mount\Windows
      3. Install optional components
         peimg /install=*srt* c:\winpe_x86\mount\windows
peimg /list c:\winpe_x86\mount\windows
         (shows currently installed optional packages
      4. If you want ImageX (or any other utilities) in the RAM disk, put them there now:
         Copy files from c:\program files\windows aik\tools\x86 to c:\winpe_x86\mount\windows\system32
         (This includes the imagex.exe utility. I suppose these really should go in the “programs” directory, to separate them from the actual OS files, but this way they are in the path so the idiot end user does not have to know where the ImageX utility is, just how to use it).
      5. Prep the PE image (don’t ask me why, it is in the directions!):
         peimg /prep c:\winpe_x86\mount\Windows
      6. capture the mounted PE instace to a WIM:
         imagex /append c:\winpe_x86\mount c:\winpe_x86\winpe.wim "MyWinPE" /verify
         (Actually appends this instance to an existing WIM)
      7. Export the appended image to a bootable WIM file:
         imagex /boot /export c:\winpe_x86\winpe.wim 2 c:\winpe_x86\ISO\sources\boot.wim
         (NOTE: the instructions on “custom images” fails to mention that you must use the “/boot” flag here!)
      8. Create the ISO:
         oscdimg -n –bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO c:\winpe_x86\winpe_x86.iso

The boy would do his grandfather proud.

Oliver:
“Not plastic food?”

Anyway, here we are at the TechEd conference 2006… my first major geek convention. Free backpacks, giveaways, freebies, and MS TechEd 2006 water bottles. Actually, I am pretty excited.

I am waiting for the “Scripting for IT Pros who can’t write code” class to begin. Speaker is Corey J. Hynes of HynesITe, Inc.

First interesting thing… the PPT slides on the screen were loaded from a desktop that was labeled “PPT Server”. Is there such a thing? Perhaps that is something we should look into for Professors and Execs. If nothing else, we could easily sell Sharepoint as a PPT server as an initial justification.

Note: It was a link to a Sharepoint Document Library, duh. I guess it had not occured to me how convenient Sharepoint would be from a presenter’s perspective.

Anyway, here is the code: 

REM Inactive Computer Object Cleanup Script
REM v1.0
REM JGM, 2006-06-05

:end
ECHO All done!

Very Cool!

Here are some first impressions/highlights:

• Default template for Blogs and Wikis

• The Wiki resembles MediaWiki (it uses the same [[link]] syntax.  The Blog looks much like any other Blog, but with the in-line posting and editing features that make Sharepoint so easy to use.  The addition of Single sign-on and Directory Services integration make the service even easier to manage.

 Oh look… it does not work!  I have submitted a bug using the Beta reporting tool.  Hopefully someone will pick it up.

• Install required "Windows Workflow Foundation, Beta2". I downloaded v2.2 from here:
  http://www.microsoft.com/downloads/details.aspx?familyid=5C080096-F3A0-4CE4-8830-1489D0215877&displaylang=en
• Also required is ASP.NET 2.0, which is installed with the .NET Framework 2.0 components (available on Microsoft Update, or as a standalone installer. Apparently my .NET 2.0 was damaged, so I ran a repair install. After ensuring that ASP.NET was enabled in IIS, the Project Server installer now runs without complaint.
• Project Server has an "all in one box" installation option. This installs and configures Sharepoint Services 3.0 and SQL 2005 Express Edition. It works surprisingly well!

Also note that the test server performing miserably.  I have expanded the VM memory to 1Gb, and performed the following steps to expand the virtual drive:

•  execute: vmware-vdiskmanager -x 15Gb <Path to.vmdk file>
• Boot to BartPE CD with Paragon Partition Manager, expanded system drive.

In the past I had many problems, although not strictly related to the utility itself:

• Networking in VMWare workstation for the WinPE 2.0 beta in the Vista AIK will not function! Apparently this is a driver issue. There is a bug registered in the Vista beta program, but I never did follow up on it.
• Networking in WinPE 1.5 did work, roughly speaking, but getting it all to function was like pulling teeth. WinPE 1.x kinda bites (not very user friendly)
• BartPE networking works great! Unfortunately, getting the “C:” drive to mount on my VMware Workstation instance was a bit more difficult. Some forum hopping revealed that others who attempt to use Server 2003 SP1 as the source for the WinPE build also have this problem. By changing the source to Server 2003 RTM, I am now able to mount the C: drive, and thus run XImage.exe.

XImage throughput was comperable to Ghost 8, and achieved almost identical compression ratios. CLI syntax is pretty straightforward. I think we have a winner…

Here is the process that I came up with:


for /f %%s in (catserv.txt) do copy /v /y c:\install\WinSSHD-Inst.exe \\%%s\c$\install\WinSSHD-Inst.exe
for /f %%s in (catserv.txt) do copy /v /y c:\install\cat_config.wst \\%%s\c$\install\cat_config.wst
c:\local\bin\psexec.exe @catserv.txt "c:\install\WinSSHD-Inst.exe" -site=WinSSHD -acceptEULA -activationCode=[insertCodeHere] -settings=c:\install\cat_config.wst
for /f %%s in (catserv.txt) do sc \\%%s start winsshd
for /f %%s in (catserv.txt) do sc \\%%s query winsshd | find /i "running" >> isrunning.txt


Note that this script required a few files to be in place before execution:

1. Sysinternals “psexec.exe” must be in place in “c:\local\bin”.
2. The WinSSHD installer must be located in “c:\install”
3. A WinSSHD server configuraiton file named “cat_config.wat” must be in place in “c:\install”
4. This script and the catserv.txt file must be present in “c:\local\scripts”. The catserv.txt file contains a simple list of the servers to which WinSSHD will be installed.

After much head bashing and tooth gnashing, I discovered that the real reason that most people recommending a solution to this problem present a client-side redirect is pretty simple:

When browsers swith from a http:// rooted URI to a https:// rooted URI, they effectively assume that they are switching to a new website (which, effectively, they are).

So, I implemented a client-side redirect by replacing the default “https required” IIS 403.4 error page with a custom page containing this javascript code:


<Script language="JavaScript">
<!-- begin hide

function goElseWhere()
{

var oldURL = window.location.hostname + window.location.pathname;

var newURL = “https://” + oldURL;

query = ” + window.location;
position = query.indexOf(’?');
if (position > -1)
{
query = query.substring(position + 1);
newURL = newURL + “?” + query;
}

window.location = newURL;

}
goElseWhere();

// end hide –>
</script>

Unfortunately, this still does not work for MS Office programs. Office refuses to recognize a redirect request (be it either server or client based), so anyone attempting a manual save to an http:// rooted URI will just get an error. Nothing to be done for it… it is an office bug. Report it to the Office team, it is not my fault.

• open a CMD shell, CD to the SAV directory on the Symantec installation media
• extract the MSI files to a local “administrative installation point”:
  

  msiexec /a “Symantec Antivirus.msi”

• Now, extract any patches downloaded from Symantec and CD to the directory that has the MSP patch file. Execute the following:
  

  msiexec /p “SAVCE-[version].msp” /a [path to admin install point]

• Now, copy the setup.exe, setup.ini, msi installer files, and that .ini file with the funny name from the SAV source directory into the “administrative installation point” directory used above.
• Edit the “setup.ini” file in your admin install point. Modify the product version string to more closely match the version just overlayed onto the installer.
• Copy in your custom SAV installer script. (In our case, we use “instsav.cmd”). Generally I just copy his out of the last production installer. Also grab the sav-managed.txt and sav-unmanaged.txt files from the previous installer. These just contain informational text to be pasted into the self-extracting archive prompt dialogs.
• Now you can wrap the whole directory into a self-extracting archive, which spawns “instsav.cmd” when extraction is complete. Of late, I have been using WinRAR. Since the 10.0.1 builds, I have been extracting the archive to “%SYSTEMDRIVE%\SAVInst”, with the option to leave the extracted files in place after installation (thus creating a local installation source). You may note that the instsav.cmd installation script uses this directory path to launch the setup.exe program.

Also note that I have made some significant changes to the instsav.cmd script. Mostly I just deleted unused sections of the script… version 10.1 does not appear to bog down the computer doing “startup scans” and “Definition scans” as earlier versions did, so I am removing the custom registry key imports that halted these scans. Also, I changed the IF NOT ERRORLEVEL 1 clauses to use the syntax “IF %ERRORLEVEL% GEQ 1″ instead, as this seems rather easier to understand from a logical perspective, IMO. Anyway, here is the script:

:begin
@ECHO OFF
ECHO – Symantec Antivirus installation script for the University of Vermont
ECHO – version 2.6, by JGM, 2006-05-15
ECHO – This Window will close automatically when installation has completed.
REM Script can be altered to allow for either managed or unmanaged client installations.
REM For managed installs, UN-comment the “goto endFirewall” line below, and uncomment the appropriate “setup” command line.
REM For unmanaged installs, COMMENT OUT the “goto endFirewall” line below, and uncomment the appropriate “setup” command line.

REM History:
REM V2.3 – changed “reg import” commands to “regedit /s” commands for Windows 2000 compatibility.
REM v2.5 – changed setup to generate MSI error log (/le option), and to run out of %SystemDrive%\SAVInst dir created by RAR extractor.
REM v2.6 – removed the “removeStartScan.reg” procedure after the :endFirewall tag, and an experiment for v10.1.x distribution, cleaned up un-used sections, substituted “IF %errorlevel% GEQ 1″ instead of “IF NOT errorlevel 1″ as a experiment.

REM If performing an unmanaged AntiVirus client installation, uncomment the following line:
GOTO endFirewall

:OSVer
REM Determine if host is running a Windows XP build:
set OSVer=notXP
ver | find /i “xp” && set OSVer=XP
IF NOT %OSVer%==XP GOTO unsupported ELSE goto spLevel

:spLevel
REM Determines Service Pack Version via registry query:
set SPVer=0
REM systeminfo |find “Service Pack 1″ && set SPVer=1
REM systeminfo |find “Service Pack 2″ && set SPVer=2
reg QUERY HKLM\SYSTEM\CurrentControlSet\Control\Windows /v CSDVersion | find “0×200″ && set SPVer=2
IF NOT %SPVer%==2 GOTO unsupported ELSE GOTO addRules

:addRules
ECHO.
ECHO.
REM Adds firewall exceptions for Windows XP SP2 hosts:
ECHO – You have Windows XP Service Pack 2! Let’s Go…
ECHO – Please wait while firewall exception rules are added…
ECHO Adding exception for Symantec Realtime Virus Scan to allow managmenet of SAV Client
@netsh firewall add portopening protocol = UDP port = 2967 name = “Symantec RTVScan” mode = ENABLE scope = CUSTOM addresses = LocalSubnet,127.0.0.1,132.198.0.0/16 profile = ALL
IF %errorlevel% GEQ 1 (
GOTO failRuleAdd
) ELSE (
ECHO Firewall rule added successfully.
)
@netsh firewall add portopening protocol = UDP port = 38293 name = “Intel PDS (Symantec AV)” mode = ENABLE scope = CUSTOM addresses = LocalSubnet,127.0.0.1,132.198.0.0/16 profile = ALL
IF %errorlevel% GEQ 1 (
GOTO failRuleAdd
) ELSE (
ECHO Firewall rule added successfully.
)
GOTO endFirewall

:unsupported
ECHO.
ECHO.
ECHO Your system is not running XP with Service Pack 2.
ECHO You do not need firewall exceptions added to your system.
GOTO endFirewall

:endFirewall

ECHO.
ECHO.
ECHO Deleting log files from previous installations…
@del /f /s /q “%ALLUSERSPROFILE%\Application Data\Symantec\Symantec AntiVirus Corporate Edition\7.5\Logs”
IF %errorlevel% GEQ 0 (
ECHO No previous Symantec AV log files needed to be deleted.
) ELSE (
ECHO Symantec AV Log files successfully deleted.
)
@del /f /s /q “%ALLUSERSPROFILE%\Application Data\Symantec\Norton AntiVirus Corporate Edition\7.5\Logs”
IF %errorlevel% GEQ 0 (
ECHO No previous Windows 2000/XP Norton AV log files needed to be deleted.
) ELSE (
ECHO Norton 2000/XP AV Log files successfully deleted.
)
ECHO.
ECHO.
ECHO Proceeding with SAV install…
REM One of the following two “setup” lines MUST BE COMMENTED OUT!
REM installation string for an UNMANAGED client install (intended for off-campus users):
“%SystemDrive%\SAVInst\setup” /s /qn /V”/qb /le %SystemDrive%\SAVInst\install.err REMOVE=Pop3Smtp,NotesSnapin ADDLOCAL=SAVMain,SAVUI,SAVHelp,QClient,OutlookSnapin NETWORKTYPE=2 RUNLIVEUPDATE=0 SYMPROTECTDISABLED=1″

REM installation string for a MANAGED client install (intended for systems that are frequently on-campus):
REM “%SystemDrive%\SAVInst\setup” /s /qn /V”/qb /le %SystemDrive%\SAVInst\install.err REMOVE=Pop3Smtp,NotesSnapin ADDLOCAL=SAVMain,SAVUI,SAVHelp,QClient,OutlookSnapin NETWORKTYPE=1 SERVERNAME=NORTON2 RUNLIVEUPDATE=0 SYMPROTECTDISABLED=1″
ECHO.
ECHO.
ECHO Product setup complete.
GOTO end

:failRuleAdd
ECHO.
ECHO.
ECHO Firewall exceptions script failed!
ECHO Symantec AntiVirus NOT INSTALLED.
ECHO Take your system to Walk-in help.
pause
GOTO end

:end

• Client side redirection
• Server side redirection

With the first approach, we direct the client to a custom error page that tells the browser to reconnect to the same URI, but with an HTTPS protocol. This can be done with javascript or .asp. Either way, the disadvantage is that form and query data likely will be lost in the dedirect. At least with the Javascript approach, you lose browse ability from MS Office applications as well.

The second approach will rewrite the URL at the server, thus preserving all URL data such as form and query info. However, this approach requires custom code to be added to IIS in the form of either an ISAPI filter or web service extension. These add-on programs frequently have conflicts with the STSFLTR (Sharepoint ISAPI filter).

I have tried a lot of junk… here are some links:
http://weblogs.asp.net/pwilson/archive/2004/12/23/331455.aspx
– General how-to on using .asp custom error pages for client side redirect… includes security configuration details, but lacks specific syntax.

http://www.codeproject.com/aspnet/WebPageSecurity.asp
– A powerful ASP.NET module to be added to your site config files. This allows per-directory auto-SSL redirection. Looks promising, but it is too much for my feeble mind to precess at present.

http://blog.opsan.com/archive/2005/10/19/1979.aspx
– Another ASP redirect script.
Note that in the feedback on this page is some excellent Javascript to accomplish client side redirection… I think this is the solution I will have to go with.

I also have tried (extensively) several ISAPI filters which emulate the Apache “mod_rewrite”. This filters work great on other IIS web sites, but not with Sharepoint… GRRRR!

After exploring the options, I decided to take advantage of our existing license pool for Symantec Ghost 8.0 (I had considered using MS XImage, but I am still seeing this as a beta product, and more trouble than it is worth on this particular project). Now the question is HOW to use Ghost.

I came across this excellent resource for “P2V” migrations, which also should work well for V2V (Virtual to Virtual):
http://www.rtfm-ed.co.uk/docs/vmwdocs/whitepaper-ultimateP2V-QuickStart.pdf
This manual comes from the following page:
http://www.rtfm-ed.co.uk/?cat=10

So, “all I had to do” was download pebuilder (which I had already done), drop the vmxnet and vmscsi drivers into the appropriate pebuilder drivers directory (already done), then activate the additional plug-ins that they provide for the vmware tools. I then needed to switch my pebuilder sources from the windowx XP i386 directory to a server 2003 i386 directory.

Ghost configuration was really easy, as pebuilder already has a ghost 8 plug in. I jest needed to extract the ghost files documented in the plugin help file into the pebuilder directory structure. Voila!

A few minutes later I had an .iSO which I mounted on VMWare and successfully booted! I am able to use “net use” to map a network drive, and then run ghost32.exe to dump an image to a separate workstation on the network.

I obtained the February CTP of the Windows Automated Installation Kit (AIK). This contains several utilities for working with and creating Windows “WIM” image files, and also includes WIMs for Windows PE 2.0.

Here is the process I am working on for building a bootable Windows PE image:

1. Install the Windows AIK
2. cd %ProgramFiles%\Windows AIK\Tools\x86 (this directory contains all of the CLI tools for WinPE image building)
3. mkdir \winpebuild\build
4. ximage /apply boot.wim 1 c:\winpebuild\build (this extracts image index “1″ from the boot.wim in the AIK directory to the specified build directory. All of the WinPE files are now available on the local NTFS drive)
5. To install additional network drivers to the PE build:
   peimg /inf=[path to NIC driver INF] c:\winpebuild\build\windows
6. copied “ximage.exe” and all other .dll files from the working AIK directory to c:\winpebuild\build\windows\system32
7. Now save a copy of the working build directory, as the next step will make irreversable changes to the build directory:
   ximage /capture c:\winpebuild\build c:\images\winpe1.wim “Custom Base Image” /compress /max
   (this captures the build directory to a WIM file “winpe1.wim” with descriptor “Custom Base Image”, using maximum image compression to save drive space.)
8. Now we prepare the build directoryfor capture. This step optimizes the build, but also prevents future use of the “peimg /inf” command:
   peimg /prep c:\winpebuild\build\windows
9. Now we generate a WIM file of our customized build:
   ximage /capture c:\winpebuild\build c:\winpebuild\boot.wim “WinPE Image with VMWare Drivers” /boot /compress max
10. In the next steps we create a separate directory structure which from which we will build a bootable .ISO WinPE image:
    mkdir \winpe\sources, mkdir \winpe\boot
11. copy bootmgr c:\winpe
12. xcopy /cherky .\boot c:\winpe\boot (relative to the working x86 AIK directory) (these three steps add files necessary for building a bootable ISO to the directory structure)
13. ximage /boot /export /compress max c:\winpebuild\boot.wim 1 c:\winpe\sources\boot.wim (copies the custom WIM to the new directory scructure… I wonder if I could just use “xcopy”?)
14. oscdimg /n /b.\boot\etfsboot.com c:\winpe c:\winpe.iso (creates a bootable ISO from the boot.wim using the boot code in “etfsboot.com”.)

AARGH! It just does not work still! No networking is available when I boot to WinPE!!!!

Anyway, I installed WDS on a VMWare instance of 2003 SP1 server. The procedure was fairly straightforward:
– Install Remote Installation Services from the Add/Remove Windows Components Wizard
– Install the WDS “hotfix” (this changes the name of the RIS service from “binlsvc” to “WDSServer”.
– Initialize WDS using either the CLI “WDSUtil”. I used the CLI, but it would seem that the GUI may be better as there is more thorough prompting for installation image media.

Following installation, I had some trouble getting another VMWare host to net-boot to the WDS server. I then tried isolating the hosts onto the VMWare “host-only” network with no further luck. Eventually I read the VMWare documentation:
http://www.vmware.com/support/gsx3/doc/network_host_gsx.html

As it turns out, VMWare runs a virtual DHCP server on the host-only and NAT virtual network adapters (this is kind of a “duh” if you think about it. By going into the VMWare “Host” menu, then selecting “Virtual Network Settings”, I am able to disable the DHCP server. Now my other virtual hosts boot to the WDS server promptly. Cool!

Now I just have to igure out how to get some images into the system…

I plan to switch to NAT networking so that I can communicate with external systems where I intend to capture the WIM images.

I am having some difficulties around Kerberos auth and also with prod DB import. Here are some helpful links:
http://blogs.tamtam.nl/mart/SharePointTipAuthenticationProblemsWhenChoosingKerberos.aspx

This happened once before. My colleague Warren licensed a product called “2TIFF” to shrink the files in question. This works well, except in his case ALL of the images in an Application folder needed to be compressed. I only need to shrink SOME of them.

After much fooling around and wasting of time, I was able to use a win32 port of the UNIX “find” command to hunt down all of the large files, dump the list to a file, and then use this file as a source for 2TIFF. The big mess of images now occupies only about 30 Mb of space.

Here are the sommand syntax details:
> find.exe “I:\OBJECTS\PURCHASE_ORDERS” -size +3M -fprint bigfiles.txt
(searches the PURCHASE_ORDERS document tree for all files larger then 3 Mb, dumps results to the text file “bigfiles.txt)

> FOR /f %F in (bigfiles.txt) DO ( “C:\Program Files\2TIFF\2tiff” s=%F d=%~dF\shrink%~pF -namegen=”[name].[srcext]” -quantize8 -ct4 -cd4 -keepexif)
(Perform a loop operation. For each loop, set the next line in bigfiles.txt to the variable %F. Run the 2Tiff program using %F as the source file. Use < %F Drive Letter>\shrink< %F relative path> as the output directory (example: when %F=”c:\objects\procurement\0\1\163.bin, the output directory will be “c:\shrinkProcurement\0\1\”).)

Here is what the 2Tiff arguments mean:
-namegen=”[name].[srcext]” -> The name of the destination file is the same as that of the source ([name] is a built in variable equal to the source file name. [srcext] equals the source file’s extention)
-quantize=8 -> sets the “quantization” level of the TIFF. This value effects the “sampling rate” and affects image quality. Eight is the maximum value, for best quality.
-ct4 -> Compression type “LZW” is used. This is the default type for color scans. We are using LZW rather than the standard “type 3″ for B/W documents because tests showed that reducing these images to monochrome yielded very low quality in some cases. We are keeping some color information to allow anti-aliasing and thus better letter quality.
-cd4 -> Sets the color depth down to 4 BPP from the source 24 BPP. CD1 would be better, but as mentioned above, this results in poor readability of the destination TIFF.
-keepexif -> preserves EXIF tags in the destination file from the source. Probably there is no EXIF info in these files, but I thought we would keep it in case I am wrong.

Warren had used the “dither” switch, but IMNSHO this makes the target document look worse and also results in larger files.

Robocopy of the image library from \\risprime\reminst is consistently a failure. I run out of drive space every time, and the Gorveler never frees up enough drive space to resume copy operations.

I followed MS advice from the KB and have tried using our backup software (Legato) to restore the whole image partition to SYSIMG1 from RISPRIME. This generally caused BSOD errors on SYSIMG1. This particular problem cleared up after I patched the iSCSI initiator from v2.0.0 to v2.0.1, set the “lanmanserver” “binlsvc” (RIS Service) and “groveler” services to be dependent on “MSiSCSI” (the iSCSI initiator service), and also disabled a misconfigured secondary NIC on the server. Now I can restore the RISPRIME volume, but the groveler does not want to start.

So, I seem to have fixed that problem by “repairing” the SIS database on the volume… (where repair=deleted the damn thing, and let the Groveler start over). The article in question is here:
https://premier.microsoft.com/default.aspx?scid=kb;en-us;247611

And here is the key information:
The SIS Groveler service database is stored in the hidden folder named SIS Common Store on each SIS managed volume. To rebuild the Groveler service database, follow these steps:
1. Stop the Single Instance Storage Groveler service.
2. Make a backup copy of the SIS Common Store folder contents to an alternate location.
3. After a backup copy of the folder contents have been made, remove all the database files in the SIS Common Store folder EXCEPT for the *.SIS and the MAXINDEX files.
4. Restart the Single Instance Storage Groveler service.

NOTE: I had to run RISetup prior to successful restart of the Groveler. All of the configuration settings for the groveler are set by RISetup. Once this is done, the gorveler restarts, and a new .mdb gets generated in the SIS directory.

- Decided to converge on the “Administative Install” method for wrapping the patches into the installer. This prevents the installed SAV instance from interfering with the patch portion of the install script. Features like “autoprotect” were preventing “msiexec /p” from working. Also, msiexec /p seems just plain unpredictable if the system has not been rebooted. I just don’t feel like injecting actions into the “RunOnce” registry key, or attempting to force a reboot.

- Added “AUTOPROTECT=OFF” to the msi options portion of the setup.exe line in the install script. This will prevent the SAV autoprotect from giving us grief while installation completes.

- Used WinRAR options to extract archive files to a specified directory: %SystemDrive%\SAVInst.
(this will cause a local cache of the install files to be maintained on the system)
(NOTE: We may wish to add a script line to delete the contents of this archive on reinstall)

- Mod the setup.ini file to contain a higher version number for the product being installed than the default (this should allow the setup.exe to install over existing SAV10 installs)

- Added an error logging option to the MSI options portion of the setup.exe line in the script (-le %SystemDrive%\SAVInst\install.err)

- Prefixed the setup.exe line with %SystemDrive\SAVinst\ to force run out of the directory created by the WinRAR extractor.

One possible work-around is to change the “Image Type” variable associated with the image (I believe this info is located in the .SIF file. I tried this once before when attempting to generate a bootable WinPE instance on our RIS server… I think it worked for WinPE, but I am not sure if it will work for standard images. It is worth a shot. Details taken from:
http://groups.google.com/group/microsoft.public.sms.tools/browse_frm/thread/dd1a317ccb619d6a/c19e3f99c61f5a09?lnk=st&q=prevent+%22computer+account%22+RIS&rnum=2&hl=en#c19e3f99c61f5a09
Here is the text of the newsgroup posting:

Normally, you would modify the RISSTNRD.SIF file for that Windows PE image
to change the “ImageType” entry from “ImageType=Flat” to “ImageType=WinPE”.
This causes RIS to no longer create the computer account (to prevent “AD
clutter”), which OSD is not going to use anyway. When making this change,
the Windows PE image will move from the “images” list to the “Tools” menu,
so you have to have the tools menu enabled via GPO to see it. For more
information on this, see the “Zero Touch Installation Deployment Feature
Team Guide” in the Solution Accelerator for Business Desktop Deployment
Enterprise Edition (http://www.microsoft.com/desktopdeployment).

I have downloaded the Solution Accelerator that is referenced, and will have a look though the “ZTI” section to see if it is any further help.

Several fixes. First off, I generated a fancy new install script:

:begin
@ECHO OFF
ECHO – Symantec Antivirus installation script for the University of Vermont

ECHO – version 2.1, by JGM, 2005-10-17
ECHO – This Window will close automatically when installation has completed.
REM Script can be altered to allow for either managed or unmanaged client installations.
REM For managed installs, UN-comment the “goto endFirewall” line below, and uncomment the appropriate “setup” command line.
REM For unmanaged installs, COMMENT OUT the “goto endFirewall” line below, and uncomment the appropriate “setup” command line.

REM If performing an unmanaged AntiVirus client installation, uncomment the following line:
REM GOTO endFirewall

:OSVer
REM Determine if host is running a Windows XP build:
set OSVer=notXP
ver | find /i “xp” && set OSVer=XP
IF NOT %OSVer%==XP GOTO unsupported ELSE goto spLevel

:spLevel
REM Determines Service Pack Version via registry query:
set SPVer=0
REM systeminfo |find “Service Pack 1″ && set SPVer=1
REM systeminfo |find “Service Pack 2″ && set SPVer=2
reg QUERY HKLM\SYSTEM\CurrentControlSet\Control\Windows /v CSDVersion | find “0×200″ && set SPVer=2
IF NOT %SPVer%==2 GOTO unsupported ELSE GOTO addRules

:addRules
ECHO.
ECHO.
REM Adds firewall exceptions for Windows XP SP2 hosts:
ECHO – You have Windows XP Service Pack 2! Let’s Go…
ECHO – Please wait while firewall exception rules are added…
ECHO Adding exception for Symantec Realtime Virus Scan to allow managmenet of SAV Client
netsh firewall add portopening protocol = UDP port = 2967 name = “Symantec RTVScan” mode = ENABLE scope = CUSTOM addresses = LocalSubnet,127.0.0.1,132.198.0.0/16 profile = ALL
netsh firewall add portopening protocol = UDP port = 38293 name = “Intel PDS (Symantec AV)” mode = ENABLE scope = CUSTOM addresses = LocalSubnet,127.0.0.1,132.198.0.0/16 profile = ALL
IF NOT errorlevel 1 (
ECHO All firewall rules added successfully.
) ELSE (
GOTO failRuleAdd
)
GOTO endFirewall

:unsupported
ECHO.
ECHO.
ECHO Your system is not running XP with Service Pack 2.
ECHO You do not need firewall exceptions added to your system.
GOTO endFirewall

:endFirewall
REM If installing an unmanaged AntiVirus client, installation may begin here.
ECHO.
ECHO.
ECHO Altering registry to remove and prevent automatic system scans…
reg import RemoveStartScan.reg
IF NOT errorlevel 1 (
ECHO Registry settings imported successfully.
) ELSE (
GOTO failRSS
)
ECHO.
ECHO.
ECHO Deleting log files from previous installations…
del /f /q “%ALLUSERSPROFILE%\Application Data\Symantec\Symantec AntiVirus Corporate Edition\7.5\Logs\*.*”
IF NOT errorlevel 1 (
ECHO Symantec AV Log files successfully deleted.
) ELSE (
ECHO No previous Symantec AV log files needed to be deleted.
)
del /f /q “%ALLUSERSPROFILE%\Application Data\Symantec\Norton AntiVirus Corporate Edition\7.5\Logs\*.*”
IF NOT errorlevel 1 (
ECHO Norton 200/XP AV Log files successfully deleted.
) ELSE (
ECHO No previous Windows 2000/XP Norton AV log files needed to be deleted.
)
del /f /q “%PrograFiles%\Norton AntiVirus\Logs\*.*”
IF NOT errorlevel 1 (
ECHO Windows 9x Log files successfully deleted.
) ELSE (
ECHO No previous Windows 9x Norton AV log files needed to be deleted.
)
ECHO.
ECHO.
ECHO Proceeding with SAV install…
REM One of the following two “setup” lines MUST BE COMMENTED OUT!
REM installation string for an UNMANAGED client install (intended for off-campus users):
REM setup /s /qn /V”/qr REMOVE=Pop3Smtp,NotesSnapin ADDLOCAL=SAVMain,SAVUI,SAVHelp,QClient,OutlookSnapin NETWORKTYPE=2 RUNLIVEUPDATE=1″
REM **This does not work!*** IF NOT errorlevel 1 GOTO setupFail
REM installation string for a MANAGED client install (intended for systems that are frequently on-campus):
setup /s /qn /V”/qr REMOVE=Pop3Smtp,NotesSnapin ADDLOCAL=SAVMain,SAVUI,SAVHelp,QClient,OutlookSnapin NETWORKTYPE=1 SERVERNAME=NORTON2 RUNLIVEUPDATE=1″
REM **This does not work!*** IF NOT errorlevel 1 GOTO setupFail
ECHO.
ECHO.
ECHO Product setup complete,
ECHO Now attempting registry alterations to prevent Definitions scans…
reg import DefwatchQSOff.reg
IF NOT errorlevel 1 (
ECHO Registry settings imported successfully.
) ELSE (
GOTO FailPDQS
)
GOTO end

:failRuleAdd
ECHO.
ECHO.
ECHO Firewall exceptions script failed!
ECHO Symantec AntiVirus NOT INSTALLED.
ECHO Take your system to Walk-in help.
pause
GOTO end

:failRSS
ECHO.
ECHO.
ECHO “RemoveStartScan” registry import failed!
ECHO Symantec AntiVirus NOT INSTALLED.
ECHO Take your system to Walk-in help.
pause
GOTO end

:setupFail
ECHO.
ECHO.
ECHO Oh No! Symantec setup program failed to complete!
ECHO Symantec AntiVirus NOT INSTALLED.
ECHO Take your system to Walk-in help.
pause
GOTO end

:failPDQS
ECHO.
ECHO.
ECHO “DefwatchQSOff” registry import failed,
ECHO but Symantec AntiVirus has been installed.
ECHO If you experience major system performance degradation,
ECHO please take your system to Walk-in help.
pause
GOTO end

:end

Changes from previous scripts are:

1. integration of managed and unmanaged installer scripts in same file – change the comments to change the install method.
2. attempts at error capturing using IF/Then/Goto
3. integration of script into one file (sans .reg import files)
4. added DefwatchQSOff.reg import to the script, moved to end of script
5. Now using “removestartscan.reg” to kill startup scans… seems to work.
6. not allowing installation of POP3SMTP plugin
7. using “setup.exe” with command line options, rather than msiexec. This avoids the need to create separate installers for upgrade vs. new install
8. Integrated 10.0.1.1007 patch into the installer (by extracting original .MSI to an “administrative install point”, then using the msiexec patch commands on the admin install point).

One issue is that copying all of the RIS Images from the current production “RISPRIME” would not complete… I ran out of space on the target volume which is the same size as the source volume. Why? Because RIS runs the “groveler.exe” service to create hardlinks for duplicate files in RIS images. My file copy utilities just copy the hardlinks as separate files, and thus I run out of space.

Presumably forcing the groveler to startup on the target volume will free up the space needed to complete the transfers… but how to do this? Groveler.exe has no command line support, and has a hard-configured schedule on which it runs (2am or some such). I want it to run now!.

Some searching reveals the following KB article:
https://premier.microsoft.com/default.aspx?scid=kb;en-us;247611

I will see if I can find this grovctrl.exe utility of legend. Sounds like just what I need.

Also found some good docs at MIT:
http://web.mit.edu/ist/topics/windows/server/winmitedu/whatsRIS.htm
and berkeley:
http://www-w2k.cs.berkeley.edu/admin/docs/docs/dhcpris.txt

Steps:

1. Install ADS on server “sysimg1″ (reusing the host “castor” from the NetWare days). Select “install MSDE engine locally” and “create self-signed certificate” options. Did not select PXE boot server option… will need to do this later. Also, created share “images” on the root of the c: drive” (note that local storage is rather limited… this may become an issue as time passes).
2. Created WinPE boot CD rom with ADS support, using ADS documentation as a guide. See notes in this blog in on generating WinPE images.
3. Created reference system:
   • install MS Office 2003 with SP1, full install from \\files\mca. Ran LISTool from the office 2003 resource kit to move the installation source to the C: drive where it will be imaged properly.

   – NOTE: did not do this on subsequent system configurations!

   • Install Networker client version 7.2.1, using “Change Journal Manger” option on all local volumes (default settings… saved installer to \\files\software\Server Resources\networker).
   • Install ActiveState ActivePERL. Latest version from activestate.com (saved to \\files\software\active perl).
   • Install Dell OpenManage Server Administrator – v4.4, with sp1 patch (from \\files\software\server resources\dell).
   • Install SSH communication Security SSH client – latest version, default settings.
   • Install 2003 server resource kit, support tools, “adminpak.msi” for 2003 with sp1.
   • Re-install Intel ProSet utility, using “modify” MSI option, then adding all components (advanced services, Intel WMI agent) – allows for NIC teaming.
   • Install GVim and Notepad++ text editors (deselect “use as default html viewer” for Notepad++).
   • Install “runtime” version of Oracle 10g client v10.2.0.1 to the “c” drive. Added tnsnames.ora file provided by catalyst staff to the %oracle_home%\network\admin directory. Per instructions from Nancy Snow, add “TNS_ADMIN” system environment variable pointing to the same directory containing the TNSNAMES.ora file.
   • add “psadm” CAMPUS directory group to local administrators group.
   • create c:\sysprep directory. Add sysprep.exe, setupcl.exe from Server 2003 sp1 “deploy.cab” file (support tools directory on the 2003 cd). copy sample sysprep.inf file from “\\sysimg\c$\program files\microsoft ads\samples\sysprep” directory. Add minor tweaks, copy back to source directory.
   • run chkdsk and defrag a few times for good measure.
4. run “sysprep /reboot” on the reference system. Boot to WinPE CD.
5. from the PE console, cd to the “tools” directory. Run:
   

   imgdeploy /capture /p c: d:\.img ““

   Then “exit” when the image is complete.
   Note:networking still not working in PE image. Aargh! Well, I guess I will just have to upload the image manually.

Lots of work to get everything going. Let us start with a 2k3-ee WinPE install:
note: turns out my 2k3ee sources are corrupted… bummer! Switched to SE, since it really makes no difference…

1. Download Windows PE, 2005 edtion from microsoft licensing site (Password ID and login info provided by Nicole Chittenden, former manager of CA at UVM).
2. Extract PE package. In my case, to F:\WinPE
3. Extract Server 2k3 EE to local hard drive – slipstream SP1 into the directory
4. at shell, cd to F:\winpe\winpe, run
   

   mkimg.cmd d:\2k3-ee-sp1 c:\winpe-2k3-ee

   (this builds a WinPE installation using the 2k3 server source to the directory specified.)

5. Now, add Microsoft ADS support files to the WinPE image: Add the files Adssupport.dll, Imglib.dll, and Imgdeploy.exe to a directory of the Windows PE build folder. These files can be found in the \Program Files\Microsoft ADS\Bin and C:\Program Files\Microsoft ADS\nbs\repository\DeploymentAgent directories where the ADS imaging tools are installed. (note that the MS documentation is a bit off on the location of these files).
6. note: If networking will be required when booting to a subnet without DHCP support, a static address will need to be configured in the winbom.ini files of the WinPE image. I added the following to assist in the generation of the Catalyst images:
   

   [WinPE.Net]
   Gateway = 132.198.113.129
   IPConfig = 132.198.113.220
   StartNet = Yes
   SubnetMask = 255.255.255.128
   WinPEFirewall = On

7. Finally, create an ISO to burn to CD. Again at the F:\winpe\winpe shell, run:
   

   oscdimg -betfsboot.com -n d:\winpe-2k3-ee d:\winpex86-2k3-ee.iso

Now let’s build a WinPE for XP Pro.

1. Extract XP Pro CD (SP2 integrated) files to the local hard drive.
2. at shell, cd to F:\winpe\winpe, run
   

   mkimg.cmd d:\xppro-sp2 c:\winpe-xppro-sp2

   (this builds a WinPE installation using the XP Pro source to the directory specified.)

3. Note that for XP, we will want to perform the additional step of adding some NIC drivers. We have a bunch of these alrady available on our RIS server. Start by copying our current XP NIC drivers from the production RIS server to a local directory (in our case, D:\drivers-xp):
   

   \\risprime\reminst\Setup\English\Images\XPPro-SP2\$oem$\$1\drivers\nic

   Again at the F:\WinPE\WinPE shell, perform the following:

   drvinst.exe /inf:d:\drivers-xp d:\Winpe-xppro-sp2

   Note that this procedure will only work for non-PNP drivers, UNLESS we do a special WinPE build enabling it (mkimg /PNP)

4. Finally, create an ISO to burn to CD. Again at the F:\winpe\winpe shell, run:
   

   oscdimg -betfsboot.com -n d:\winpe-xppro-sp2 d:\winpex86-xppro-sp2.iso

FTP into Norton1.uvm.edu does reveal that the file is not actually there. The quick fix here is to resynch the LiveUpdate directory from SYmantec. To do this:

1. On Norton1, Launch “LiveUpdate Administration Utility”.
2. Go to Tools>Options, then select “Retrieve new and previously downloaded updates”, then “ok”.
3. Click “retrieve”, wait for the process to complete.
4. Change the previously set option back to “New updates only”.

Now test out LiveUpdate to see if the missing file has been restored.

To set the mode for users, you must enter the “User Profile Administrator” program that installs with XS Admin. You can change the global default, and/or the default for specific users (but not for Groups???!!!). Without further configuration, this option becomes fixed, and the user cannot change it.

However, in App Gen (part of a Full ApplicationXtender install), you can set a global option per-user or per-group called “Configure WS”. Once set, this allows the user to change ALL WebXtender user-configurable options, including the client mode.

Note: Setting this option in AppGen does not enable it for the user automatically! You must restart the WX service in order for the change to take effect! AARGH! (Recommended approach is to run the “Component Setup Wizard” which ships with XS Admin).

To accomplish this, I just needed to follow the previously documented manual installation routine, and take note of what changed on the system (specifically, I had a look at the REG text files generated by the ODBC installation script).
Advanced Installer lets to specify source files from ANY location, to be installed to a specified Program Files target. You also can specify Environment variables and Registry settings that you want performed during the install.

I just shipped the Install Directory to “University of Vermont\Oracle 10g Client”, and added an “admin” subdirectory for the TNSNAMES.ORA file. Then I set the PATH, SQLPath, and TNS_Admin environment variables. Finally, I specified the required ODBC registry changes, and built the MSI.

Since doing the build, a new version of OC 10g Instant Client has become available (v10.1.0.4). I have updated the installer to use these files instead. Making this change is fairly simple. All you have to do is open the original Adv Installer package specification file (.AIP), take note of the location of the source files, then drop the updated files into that location. If there are any new files, or files that are no longer present, you need to update the AIP to reflect these changes. Change the package version number, then rebuild… easy.

1. At the command line, go to the AX 5.20 installation directory.
2. Run
   msiexec /a AxSetup.msi TARGETDIR=[working directory]
3. Assuming the MSP file is in the same directory, run
   "msiexec /p /a [working directory]\AxSetup.msi"
4. Now just zip the working directory into a single file.

We do have some other options that may help with deployment:

1. The “XSCM.Config” file from “\Documents and Settings\All Users” into the final archive directory, along with a script that drops this file into place on the target system. This will save installation staff the need to locate the setup file on first run of the application
2. The install directory can be added to a self-extracting zip, which calls the SETUP.EXE.
3. SETUP.EXE has command-line support, documented in the AX Installation guide. Essentially, we would run
   SETUP MsiExec.exe /i "AxSetup.msi" /QB INSTALLLEVEL=[install_level]
   where [install_level] is a number from 1 to 3. 1=Retrieval install, 2=Scan, and 3=admin install.

I have been concerned about the apparent need to provide two installers… one for upgrades, and one for new installations. This is an issue that came up with SAV 9, mp2. Fortunately, I was able to find a decent thread on installation techniques at Novell “Cool Solutions”:
http://www.novell.com/coolsolutions/tip/15090.html

I have changed our installed to run the installer using “setup.exe” (an install shield program), instead of “msiexec”. When using setup.exe, the installer appear to deal well with existing installations.

I have also added an additional .bat to the installer script… RemoveStartupScan.bat. This runs “reg.exe” to import a .reg file obtained from Symantec. The reg settings included disable the startup “quick scan” (DoScan.exe) that has been irritating Symantec clients since the release of 10.0. Symantec says that DoScan has been “fixed” with 10.0.1, but I still do not like it.

Finally, I am allowing installation of the Pop3Smtp component, although I suspect that we will just have to rip it out again in the near future. I thought we might give it a chance for now.

After a lot of mucking around with gnuwin32 tools, I decided that the best “quick fix” was to do the following. The Windows Server Recource Kit is required:

1. As someone with read access to the entire filesystem, run:
   dir /s /t:c \\files\shared | qgrep /y -E “.dbf .apr” > dbreport.txt
   alternatively, one could use the gnu “ls” command to get similar output in a slightly ritcher format.
   the /t:c switch forces dir to display the last-changed timestamp rather than the default last-accessed. The /y performs a case insensitive grep. -E parses results on the end of the line only.
   note as a fun side project, I had to disable viewing of the ~snapshot directories on our NetApp filer while the query was running, as the dir command insisted on parsing through all of the snapshot directories. Aargh!
2. next, I import the txt file into excel. I used the “Data->Filter->Advanced Filter” menu to mask the many duplicate records in the sheet, then past the filtered view into a new sheet.
3. To get a better grip on the actual number of production Approach databases, I saved the filtered sheet to a new text file then ran the following command:
   type dbreport-filt.txt | qgrep -y -E “.apr” > dbreport-apronly.txt
   this generates a list of only the *.apr records in the file. I then re-import into a new Excel sheet. All three sheets have been shipped off to Doug for digestion.

UPDATE:
Doug has asked for a new report. I thought I would try doing it with “POWERSHELL” this time:

gci \\files\shared -recurse -include *.apr,*.mdb -exclude ~snap* | Select-Object LastWriteTime,Length,Name | export-csv dbhunt.csv

We are using the “get-childobject” (alias “dir” or “gci”) to get a recursive (-recurse) directory listing of \\files\shared. We are excluding those pesky ~snapshot directories (-exclude ~snap*), and filtering for only APR and DBF files (-include *.apr,*.mdb – (NOTE: I got the expression via trial-and-error… I cannot find a good reference on PowerShell regular expressions and wild card matching. I would have thought “$\.apr|$\.dbf” would work, but it did not.)). We the pipe (|) to select-object and choose only the LastWriteTime, Length, and Name attributes of the listed files. Finally we pipe to “export-csv” to sent the search results to a csv file.

I am using the PowerShell 1.0 RC1 refresh for this report. Note that I am able to catch both APR and MDB file types in a single pass, and also I am able to filter the output to include only the attributes that I want. Finally, I can export directly to a CSV file for import into a spreadsheet. I suppose I could also have used the “sort” features in the pipeline to segregate the APR and MDB files to the top and bottom of the output file, but I will just do that in the spreadsheet. Another sort option would be to “remove duplicates”, but this could result in some data loss as many DBs may have the same name, but with different content. Somthing I could not figure out how to do in the time available how to auto-format the “Length” data in Megabytes… I know I saw this in a PowerShell demo, but I cannot find my notes, and I can’t glean this from the online documentation).

Ooh! Even better:
gci \\files\shared -recurse -include *.apr,*.dbf,*.mdb -exclude ~snap* | Select-Object DirectoryName,Name,Extension,Length,CreationTime,LastWriteTime | sort DirectoryName | Export-Csv \\files\flex1$\qtree-home10\d\dsv\winhome\dbhunt.csv

In this pass, I have added additional properties to the “select-object” command which I want exported to my CSV report. These properties are the “DirectoryPath” to the file, in addition to it’s creation time. Also, I have a separate field for “extension” to ease in reporting later on. I also have added a “sort” command to the pipeline so that the output file will already be sorted by DirectoryName.

I think this will take about 3 hours to run, so I am just going to dump the report straight to Doug’s home directory. Huzzah!

1. Download and install LU Admin v1.5.4, required to fetch SAV10 updates for our internal LiveUpdate FTP server. Installed over existing version, purged and re-downloaded alll current SAV/NAV related files, and also updates for Symantec products commonly used at UVM. note: needed to set the LU Admin tool to “download previously retrieved updates” during the initial download… otherwise it refuses to get new definitions!
2. Uninstall Quarantine, Quarantine Console, and Symantec System Center on Norton1, Norton2.
3. Attempt to run SAV installer by running setup.exe at the root of the SAV10 CD… setup appears to run, but all it actually does is remove files from the server! Aargh! Attempt to use the “Server Deployment” tool to push updates to Norton1 and Norton2… the wizard forces me to re-create the “UVM Antivirus 1″ group, and to specify a username/password for the group… I do this. The wizard then copies installer files to the hosts, and then hangs for half an hour. I am forced to cancel the installation.
4. reboot both systems, then attempt to run the regualr installer again. This time, the installer works (although SAV is now installed in the default “%systemdrive%\program files\Symantec AntiVirus” folder, instead of the original folder from the SAV 9 install. Hmmm….
5. install Central Quarantine on Norton1. Install system center and quarantine console on norton1 and norton2
6. Upon launching SSC, there are now two “UVM AntiVirus 1″ groups, each with one of the NORTON parent servers. The group with NORTON1 is non-functional, as it reports that NORTON1 is DOWN (even though Norton1 appears to be running all of its Symantec services). Aargh!
7. Fix hangs when attempting to view NORTON1 history files by archiving old (and probably corrupt log files. To do this, I stop the SAV service, then remove all files from c:\documents and settings\all users\application data\symantec\symantec antivirus corporate edition\7.5\logs.
8. SSC listing of NORTON1 system status as “down” could be the result of server overload… see symantec KB article:
   
   http://service1.symantec.com/SUPPORT/ent-security.nsf/529c2f9adcf33a1088256e22005026f1/6a0fbf5fc81a6c9588256d6c0060fa5e?OpenDocument&prod=Symantec%20AntiVirus%20Corporate%20Edition&ver=9.0&src=ent&pcode=sav_ce&dtype=corp&svy=&prev=&miniver=savce_9.0
   
   nope… that did not help at all…
9. called Symantec tech support. They speculated that the upgrade of the “UVM AntiVirus 1″ server group was botched. The workaround was to first move the functioning “Norton2″ server to a new, separate server group. Next, we remove the HKLM\software\intel\landesk\virusprotect6\domaindata registry key (after backing up the registry). This effectively lobotomizes Norton1, and makes it forget that it is the primary server in the AV group. After a reboot, the UVM AV 1 group is again accessible via SSC. We re-promote NORTON1 to primary server of the group, and move Norton2 back in. Our AV group policies are totally shot, so I need to rebuild all policies. Joy.
10. Scheduled tasks on the operating systems have stopped running. Reason is that path to .exe files changed with the upgrade. I have updated all of the executable paths.
11. Roaming services have been implemented… this will allow SAV 9+ clients to load balance between NORTON1 and NORTON2 parent servers.
12. Important SAV10 server settings… new feature is “performance tuning”… I needed to activate management of back-level SAV clients. Also, I set options to skip over clients that are not checking in with the parent server. This will allow faster push of updated definitions as they become avialable.

• SYSTEM volume was almot full on Norton1. Stef found scads of MSFTPSVC log files and deleted them.
• SAV service would not restart… apparently due to corrupt virus definitions. Repaired by following advice at Symantec KB:
  http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2002102209110448?Open&src=ent&docid=2002080708594148&nsf=ent-security.nsf&view=docid&dtype=corp&prod=Symantec%20AntiVirus%20Corporate%20Edition&ver=9.0&osv=&osv_lvl=
• We set the IIS service to keep it’s logs on the D: (vol1) drive instead of SYSTEM. Geoff will work on a script to purge logs >1 week old
• We set the FTP service idle connection timeout from 900 seconds to 120 seconds to cut down on hacker locking FTP service connections.

RESOLVED that we need to look at changes to services on Norton1/2:

• auto purging to old quarantine files
• auto purging of AV service events for faster loading of log viewers
• load balancing of client across Norton1/2 for better performance/reliability
• potential benefits of upgrade to SAV 10.0

The only service that has been installed on any of the imaging servers that appears to be of any potential relevance is the “Legato Licensing Server” on DOCIMG1. Netstat -ano reveals that this service is listening at port 9152… this port is not available through the internal firewall.

I will switch this server to port 6252 (currently port of the 100-port range for RPC’s made available through our internal firewall). This setting is made in the registry at:
HKLM:\SOFTWARE\Legato\License Server\RPC\
REG_SZ Value: TcpIpEndPoint
After restarting the service and running another Netstat -ano, I now see that the license service is listening at port 6252. Yeah!

Update: Last week our WX instance broke… EMC support blames this on the port change. I have reverted to port 9152, and will need to get this exempted on the firewall.

Our thoughts are to provide a script that will:

1. Create regular fixed system partition sizes
2. Install standard system components: Backup, Power, Management, SNMP
3. What else? Std. local admin password?

??? What about the Dell partition, with Utils??? Is it worth it?

Some discovered resources:
Unattended.txt -> When running the windows setup ‘.exe’ files, you can use a /unattended= argument to use different answer files for different workgroups. The “Setup Manager” tool can be used to generate a “Uniqueness Database File” (UDF) which can be user to define computer names, and apparently to link different answer files to these defined machines as well… I will need to look into how this is done.

anyway, here is what I did…

-Go to oracle.com, downloads, database, 10g Instant Client, log in, fetch the Instant Client Base package, and the SQLPlus files. also grabbed the ODBC files, even though I do not really need them at this time.
-Extract all of these .ZIP files to C:\Program Files\Oracle InstantClient\
-SET the System Variable PATH to include the instantclient_ subdirectory of the above path
-SET the new System variable SQLPATH to the same value just appended to PATH, above
-SET the new System variable TNS_ADMIN to the same as SQLPATH, but append “admin”.
-Create a new folder “admin” in the instant client directory
-Create a TNSNAMES.ORA file in this location, past required entries into it (copied from the %ORACLE_HOME%\network\admin directory on the server “DOCIMG1″).
-Run the ODBC Installer .BAT file in the instant client directory
-Log out, then log in again to initialize the newly set variables.
-Test connectivity to the IMG databases using SQLPlus.exe:
C:\> sqlplus @imgy.world

Now I can install XSAdmin and ApplicationXtender applications. Connecting meerly requires that I select the correct Data Source provider (Microsoft OLE provider for Oracle).

These also should be a “Type J Personality” for “jerk”.

(Throught attributed to Steve Cavrak)

Citrix performs “automatic printer creation” for ICA client sessions. When a client uses ICA to connect, the Citrix server creates a “local” printer that points back down the ICA pipe to the client’s locally defined printers. The Server must have a driver which matches the client’s. If I have a Canon IR2300 printer defined locally, the Citrix server must have this same driver loaded and ready. Applications on the server will format print jobs using it’s own driver, and then send them back to the client.

Exceptions to this client/server driver 1:1 driver mapping can be made in the wtsuprn.inf file:
%System Root%\system32\wtsuprn.txt
Here, you can assign specific driver names to a different driver already present on the server. Most commonly, we map printers to a relatively generic PCL driver such as the HP LJ 4000 or LJ4. This is a Good Thing, because it allows the sysadmin to avoid loading untested/unstable drivers (think “Savin”) on the terminal server.

Unfortunately, this does not always work. Some printers, such as most Savin printers we have worked with, simply refuse to map, and they do not even have the courtesy of logging errors on client connect.

Citrix recommends using the “Universal Printer Driver” for troublesome printers. Unfortunately, the UPD is not available under MetaFrame 1.8 (which is what we are using). So, the short answer to the question “why is my Savin printer not working with Citrix” is “because it is not supported”.

Additional discoveries:
You can see which printers were autogenerated for a client by looking in the registry.
HKU://Printers/Citrix/
shows all of the printers mapped for a currently logged-in user. Note that reg keys are loaded at user login time.
You can determine a user SID by issuing the following command line:
dsquery user -samid | dsget user -sid

If you want to see the user hive for a non-logged in user, you will have to import it from:
:\Documents and Settings\\USER.DAT

I uploaded the installer .zip to d:\install, then extracted. There are documentation PDF files in this folder. Following the instructions there, I have created a service account for the “Data Manager” (or primary DiskXtender) service. The account is CAMPUS\sa_dx-DataMngr. The account has been added to the local administrators group, as per the documentation.

Outside of that, all I have done is run the main DX setup.exe. The oply two options that I set were 1) the name of the service account to be used for the service and 2) the name/location of the Legato Licensing server. (The installer notes that the license sever on DOCIMG1 does NOT have a license for DX at this time, as noted above).

Note that I did NOT install the MediaStor application. This component does not appear to be required in our case as we will not be managing removable storage devices with our installation of DX.

After the install, I started up the DiskXtender Administrator program. I then ran the Service->New Extended drive wizard, and added the “I:” drive (mounted iSCSI LUN on “blocks.uvm.edu”). It is requested that you configure a number of options for the “Extended drive” at this time. I accepted the defaults for most options, other than “drive scan”, which I changed from “disabled” to instead run once a week on Saturday at 2:00 am.

The wizard also requests that you setup a “media folder” for the extended volume. I quickly added “hr_images”… I will wade through the documentation to see if I really need separate media folders for the whole volume. I would rather avoid touching this interface in the future… certainly I do not want to make setting up new media folders a prerequisite for new AX applications, if at all possible.

I am feeling a bit down today. It seems we never make any real headway here in CIT. I am wondering how we can be more effective?

A little work needs to be done to get the two system to co-habitate on the same server.

Initially, I had throught to use the “PXELINUX” boot system which ships with Unattended as the primary boot system, adding additional entries to the default.cfg file in the TFTP boot directory. However, I have been unable to find any “how to’s” for this configuration.

Instead, we will attempt to use RIS for the primary boot image. We will then add Unattened’s PXELINUX boot files as a “Tool” in the RIS setup menu. This was done following instructions at:
http://syslinux.zytor.com/ris.php
(we omit the step that suggests altering the .osc file).
Note that the “Unattened” tool now shows up under the “RIS Service” tab in the DSA.msc MMC console (AKA “Active Directory Users and Computers”).

Since I had previously requested special DHCP configuration options for the 104.0 subnet where our pre-prod RIS/Unattended box resides, I have had to request these options be altered. They were:
next-server 132.198.104.170
filename “pxelinux.0″ (note the quotes)

For RIS, the filename option needs to be changed to “/OSChooser/i386/startrom.com”. (note again the very important quotes)

Now we need to enable the “Tools” menu on the RIS server. Through near-random web searching, I discover that this is a group policy setting. For starters, I make a new GPO called “CIT – RIS Policy”. This policy is linked to the “PEOPLE” OU with NO FILTERING (at present… probably need to change that… probably make it part of the “Windows Services” user policy). I disable COMPUTER side processing, then under “Windows Settings->Remote Installation Services”, I enable “custom” and “Tools” options. NOTE that using loopback processing and linking the policy to the server’s OU does NOT work… apparently GP processing in the CIW (AKA the RIS Client Installation Wizard) is not that sophisticated.

When we netboot to the RIS server and login, we now get a TOOLS option… Huzzah!!!! When we select Tools, then Unattended, Unattended starts right up! Double Huzzah!

Interesting to note that MS maintains that OEMs will provide Tools snapins for firmware updates and the like. I will have to see if Dell makes these available.

Also consider emSoft’s RIS menu editor:
http://www.emboot.com/FREE_RIS_Menu_Editor.shtml
(This is a free download of the 1.0 version… 2.0 is a cheap pay-ware app).

Currently, CIT uses a Microsoft RIS on three servers to deploy MS operating systems to computers purchased through the Depot.

One system, “RISPrime”, is installed permanently in the Depot. This system is located at IP 132.198.115.115 and is joined to the production “CAMPUS” Active Directory domain.

Two security groups control access to the RIS server (beyond “authenticated users”, all of whom are allowed access to RIS-boot and pull down disk images).
First, “CIT – Workstation Join” is used to grant rights to populate computer objects into the RIS-Workstations,CIT,Resources,campus,ad,uvm,edu container. These are the users who will be able to auto-generate computer objects when running RIS.
Second, “CIT-RISImageMakers” are granted the rights to add disk images to the “RemInst” share on RISPrime, under the Setup->English->Images folder.

The two remaining RIS systems are not in active use except during back-to-school system deployment and port-deployment help-fairs. These systems each run self-contained Active Directory environments (complete with DHCP and DNS services), and have a separate mirrors of the RISPrime disk images.

James_S_Davis@dell.com Dell Professional Services

www.learndell.com

do Adding packages to software repositories

1390° to support dell. cm

ideate” vi sure “so

is 4.4 _

1>2400 series and higher

can auto-run update all

firmware