Microsoft's Exchange group has a odd view of scale

If you look at Microsoft’s install documentation for Exchange 2007, they seem to have an odd sense of scale.
Planning for a Standard Exchange Organization
http://technet.microsoft.com/en-us/library/bb124367.aspx
…Other distinguishing characteristics of the standard Exchange organization include:

• The Service Delivery Location (SDL) and Client Service Location (CSL) reside on the same local area network (LAN).
• There are more than 1,000 mailboxes in the organization.
• There are fewer than five routing groups, and between one and five Active Directory directory service sites. Multiple locations and Active Directory sites introduce the multi-site routing protocol and role discovery algorithms, as well as a requirement to use IP site links.

Standard = 1000+ Mailboxes? I don’t think I have a single STANDARD installation, then…

This also explains the lack of support and tools for smaller companies.

VBScripts

I've decided to post some of the VBScripts I've built over the past couple of years. I'll try to organize them as I go along but here's some:

• Clear temporary AutoCAD files from a Server
• Clear temporary AutoCAD files from a Workstation
• Setting the AutoCAD Flex License Server
• An example of a multi-purpose logon script that maps drives only if servers are pingable, sets internet favorites, and configures zone settings.

I've made the majority of my scripts with a help menu available from a /? command line call

Change the Version History page in SharePoint v3.0 to show metadata for all versions

I did a lot of experimenting today and found out that the following change:

If you want to change the view so that is shows the full metadata for every line, perform the following steps:

• Logon to the server hosting the SharePoint site
• Create a backup of the Versions.aspx page at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\versions.aspx
• Open the Versions.aspx page
• Delete lines 528 through 533:
  528 object val = itemcurr.GetFieldValue(field); <% object val = itemcurr.GetFieldValue(field); %>
  529 object valprev = null;<% object valprev = null; %>
  530 if (itemprev != null) valprev = itemprev.GetFieldValue(field); <% if (itemprev != null) valprev = itemprev.GetFieldValue(field); %>
  531 if (((val != null) ? val.ToString() : String.Empty)<% if (((val != null) ? val.ToString() : String.Empty) %>
  532 != ((valprev != null) ? valprev.ToString() : String.Empty))<% != ((valprev != null) ? valprev.ToString() : String.Empty)) %>
  533 {<% { %>
• And delete line 558:
  558 }<% { %>
• Save the file and then all sites will have this view of the version page:
• Repeat the process on all front end servers.

Now, I'll go back and see if I can get it to bold the changes...

Microsoft support was correct this time

After the long and painful process of moving 1.2 terabytes of badly organized data from one server to another, I found out that Microsoft Business Critical Support was right this time. In my last post, I was wondering if they were full of it when they said it had to be a hardware issue. However, after destroying and re-building the external array, the DFS sync worked perfectly.

If you're wondering why it took so long to move data, it was because this client regularly exceeds 256 character file names and command line copy utilities like XCOPY and RoboCopy fail routinely. I have to use BackupExec or NTBackup to do a full backup and restore.

Oddball problems with DFS and hardware

I moved an external arry from one server to another and suddenly have a bunch of DFS problems. I opened a case with MS critical support we walked through a ton of options to figure out what's wrong and they finally settled on a hardware issue. I think they might be blowing smoke but we'll see later this week.

It's over a terabyte of data so I'm not looking forward to this migration process.