Thursday, February 12, 2009

Exchange 2007 SP1 RU6 released yesterday

The Exchange team RTW'd SP1 RU6 yesterday.

The KB Article and Download are now available

Some important fixes included in this rollup include: (from the Exchange Team blog )

  1. Fix for a security issue which has been assigned a severity rating of critical. More information about the issue can be found in the Microsoft Security Bulletin http://www.microsoft.com/technet/security/bulletin/MS09-003.mspx
  2. Fix to allow Internet Explorer 8 to be used for Outlook Web Access (OWA) 2007. This does not include the OWA 2007 S/MIME control. We are still working on some changes in the control to make it work better with Internet Explorer 8. We will be releasing an updated version of the S/MIME control in a future rollup. Users using the S/MIME control should continue to use Internet Explorer 7.From the installation perspective, a reminder that the rollup installer will overwrite any OWA script files if required to ensure proper operation of OWA. If you have customized the logon.aspx page or other similar OWA pages, you will need to redo any customization after installation of the rollup.
Also of note from the Exchange Team blog post, there is a new Technet forum just for Exchange updates:

http://social.technet.microsoft.com/Forums/en-US/exchangesoftwareupdate/threads/

Labels:

OCS 2007 R2 Group Chat Installation - Part 1, Server Installation

If there is one thing in Group Chat that is similar to OCS, it's definitely the icons. If you were not aware, the Group Chat functionality was an acquisition of a company named Parlano in the summer of 2007. Because of this, the integration with the rest of OCS R2 isnt quite where I would expect it to be. I expect in future SP's and versions this will become more tightly integrated.

A note, on Group Chat pre-requisites. I did this install on my existing standard pool which is not recommended. It should be on a separate server.

This is a screenshot of the IIS features I have installed. I have not yet found any article on group chat pre-requisites on a fresh server. I will need to do this soon and update this post.

Downloads:
ServerSetup
ClientSetup
AdminSetup

I will review OCS 2007 R2 Group Chat in three or possibly four parts.

  • Server Installation
  • Administation Installation and configuration
  • Client deployment
  • Usage, recomendations

Lets dig in with the Server Setup.exe. I wish that this was more OCS integrated from the start. We begin with a VERY non MS DOS window. This launches the Group Chat Server install, that looks and feels familiar.



From there, Accept terms, enter user/company, choose features… two choices, Chat Server and Compliance Service. Both install by default.

Get a warning about MSMQ not being installed. This might be due to my eval install rather than real standard. Either way, if you plan on using Group Chat, or archiving/monitoring, you need MSMQ.

And then…. I am removing backup files:


And I did this twice to be sure. Yep, that's a window popping under to install. And "Server configuration" with a new icon. Of course, these are the pains of integrating Parlano, whom Microsoft acquired only 2 years ago.


Choose server and DB name:


Note here: You do need to manually create this Database.

Next screen, you can choose a different DB for compliance (likely policy recommended)

I chose the same for technical ease.



It's around this point I noticed the menu on the left gave no knowledge of how many steps remained. Not a big deal, but would be nice to see that the list has a start and a finish.

Here is where we set our Super Users:



Enter your OCS pool name, then choose Browse to select the MTLS cert to use.


The next few screens, I am setting a few service accounts up. For simplicity, I used my Domain Admin account for most of these. In a production environment, I would ABSOLUTELY have separate accounts for these.


For some reason, the browse button on this dialog was not working for me. Not a big deal. This should be a UNC path. I made it on the same machine for my instance.

I did not delve into the Compliance Adapters at all.


Next screen was Web Service Settings. Same deal on the UNC share:

Final Overview before hitting Install:

When you hit Finish, you will be alerted if any of the service accounts are granted the log on locally or log on as a service right.

Then we flip back to the MS installer and we are done!


Once this is installed - you will only have the OCS R2 Group Chat icon in your administrative tools.


Launching this allows you to view status of services and stop/start them as well as modify the service accounts.

I am not yet sure why the Web Service is listed as stopped. The W3SVC is running in the Services control panel, however.

Within this, File - Configure Server Settings allow you to modify pretty much ANY of the settings you specified in the installation. I am not going to review each of these, as I think it would be repetitive.

Next up - the Administrative Tool!

Labels: ,

Wednesday, February 11, 2009

Installing the OCS 2007 R2 administrative tools on an x86 Domain Controller

Took me a bit to find this one. The installers for the admin tools are in \support\i386.

There are 5 files in here, and depending on the state of your DC, you might need them all.

The proper order of operations, I found out the hard way, but each install tells you what it needs for a pre-requisite:



Well, at least they give us warnings!

The proper order of installation is:

  1. sqlncli.msi - The SQL Native client
  2. vcredist_x86.exe - the Visual C++ 2008 redistributable
  3. .NET framework 3.5 SP1 (not in this directory - download here)
  4. OCSCore.msi
  5. AdminTools.msi

I kind of wish they wrapped an installer around this all like they did the regular OCS 2007 R2 deployment. The notes above say to run setup.exe, which there is not one of - there is the setupse.exe and setupee.exe, but those are x64 binaries, so they do not apply here.

Keep in mind your mileage may vary, as you may already have some of these installed on your x86 boxes.

Labels:

OCS 2007 R2 - fresh install - Monitoring service failing to start

I had this happen in a lab domain. For some reason the "Office Communications Server Monitoring Agent" would start, then immediately stop, with no real errors on screen or in the event log.

On screen, I got the "some services stop if there is nothing to do" error.

I found this thread:
http://social.microsoft.com/Forums/en-US/communicationsserversetup/thread/418720e6-4c61-46e2-81ac-21350c19e223/

I installed Message Queuing using:
Servermanagercmd.exe -I MSMQ-Server

Then I was able to start the OCS monitoring agent service without issue.

Labels:

Monday, February 09, 2009

Hyper-V Sidebar app!

Throwing up the new "Why didn't I think of that" label for this one:

Download:
http://mindre.net/post/Hyper-V-Monitor-Gadget-for-Windows-Sidebar.aspx

Very handy app!!

Immediate dbl click RDP to my VM's!


Labels:

OCS 2007 R2 Deployment, Part 4

We have already prepared Active directory, Installed OCS 2007 R2, and configured the server and certificate.
In order to have internal IM and LiveMeeting capabilities, we only need to do a few more things.
  • Create required DNS entries
  • Enable users for OCS 2007 R2
  • Deploy Communicator Clients
  • Enable Audio/Video on clients with new hardware


So, first off.. If you are only doing internal OCS, you only need to be concerned with your internal LAN DNS.

Communicator looks for several DNS entries. If you turn on event logging in the client, you learn it looks (in this order - replace domain.com with your internal FQDN)

  • SRV record for SIP

  • sipinternal.domain.com

  • sip.domain.com

  • sipexternal.domain.com

I created sip.domain.com as a CNAME to my OCS 2007 R2 server:



Enabling your users is very simple from ADUC once the OCS administrative tools are installed. Since OCS 2007 R2 is 64 bit only, I have yet to find the 32 bit admin tools. (If you find this, please link me and I will update this post!)

Right click the user in ADUC and choose Enable user for OCS


Choose the server or pool, the SIP naming convention (I recommend using email address), then next and finish.

Deploying the Communicator 2007 R2 client (OC 2007 R2, but I find that naming to close to not be confusing) can be done in MANY ways. It is supplied as an MSI, so you can:

  • Put the MSI on a file share and email users the instructions
  • Deploy via GPO
  • Logon Scripts
  • Deploy using SMS/SCCM/SCE

Once deployed, for domain machines with Communicator installed, it is as simple as launching in order to get the IM and presence functionality. Beyond this, there is audio/video which requires PC's with webcams and headsets with microphones. If this is not pre-existing, I typically budget 80-120$ per node for the addition of hardware as needed.

After installing our webcams and microphones, internally we were able to do VOIP and Video calls immediately after deploying the client.

Labels:

Windows Server 7 Beta Feature Focus - Migration solutions for WS08 R2

I viewed a LiveMeeting today on migrating to WS08 R2. The full transcript should be available here later:

http://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=488&DownloadID=14733

Benefits of migrating to 2008 R2:

  • Clean OS installs exhibit more stability

    • Reduces risk and downtime
    • Performs most of migration tasks while the old server is still operational
    • Verifies migration and benchmark performance before switching to the new server
    • Rolls back to old server if migration fails
  • Provides a transition path from

    • x86 to x64 OS (WS08R2 is x64 only)
    • Physical to Virtual (and vice versa)
    • Full server to server core (and vice versa)

    Windows 2008 R2 migration guides for AD/DHCP/File and more are online now here:
    http://technet.microsoft.com/en-us/library/dd365353.aspx

Supported Scenarios:


General Process:


They than ran through exporting DHCP on a 2003 x64 server - the password is used to encrypt the exported data.



And then re-import on the Windows 2008 R2 server with the DHCP feature installed (but not configured)




Then, the importResult variable can be used to review/parse for any warnings or errors from the import. The example they used was the administrator and guest account not being imported because it already existed on the target machine.

They then show the DHCP and user data imported successfully.

I did ask a question if they plan to allow you to scan and export and have the import install the necessary roles and features, and they did intend the import/export to do this in a later version. Apparently they liked this question, because I won something. Yay!

Then they moved on to a file server migration. Basically similar process for file shares, export, then import, and it recreates NTFS and file shares on the target server. Very neat stuff, and nice to finally have some tools for role migrations!


Labels:

Impact of ESX snapshot backups on Microsoft database servers

Up until Update 2, ESX 3.5 uses a VMWare tool called the Sync Manager as part of the snapshot backup process. The Sync manager quiesces the file system (pauses all incoming I/O requests and dumps dirty data to disk) before the snapshot backup is taken. This allows the backup to file-system consistent.

If you were to take a snapshot without pausing the I/O requests and then restore the snapshot, the virtual machine will start up for the first time thinking that it is recovering from a power failure type of crash. This is because the recovered system will not be able to find the I/O requests that were stored in the memory (RAM) at the time the snapshot was taken.

What does this have to do with database servers? For servers housing databases (Active Directory, Exchange, or SQL servers), stopping I/O requests with the Sync manager halts incoming requests to the database without notifying the database of what is happening. The database is waiting on that information to arrive – so when the data doesn't come in when expected, errors are logged to the event log and in some cases, the databases become corrupt. I happened to find this out on an active directory domain controller, and the sequence of errors looks like this:

First, you'll see event ID 1 logged with source LGTO_Sync. This is the Sync driver starting to do its work quiescing the file system.

On domain controllers, AD requests will begin to fail. The description will differ based on the request, but the Event ID stays the same.

For domain controllers running DNS, dynamic updates will fail as well:

For DHCP servers, you will see this:

On Exchange servers, you'll see Autodiscover errors:

If you are seeing these errors, stop using the sync manager now. Eventually you will corrupt your database.

Workaround
Stop quiescing guest database servers before taking snapshots, and start adding snapshots of virtual machine memory to your backups. Most backup applications allow you to do this. If yours doesn't, you can script it using vimsh.

Example:
vimsh -n -e "vmsvc/createsnapshot [VmId] [snapshotName] [snapshotDescription] [includeMemory]"

vimsh -n -e "vmsvc/createsnapshot XXXX FIRST_SNAPSHOT MY_FIRST_SNAPSHOT_1"

By taking a snapshot of the guest machine's memory, you are creating a full snapshot. When you restore, you restore the memory on top of the file system. When the machine starts, it will be able to access all the necessary information in memory to start normally - no crash.

Resolution
To combat the Sync Manager problem, ESX has released update2, which includes an ESX VSS tool that integrates with Microsoft VSS. It works by using the windows operating system to hold I/O requests, eliminating the need for the sync driver. When the operating system is in charge of halting its own I/O activity, the databases are notified that a backup is taking place. The databases can then pause their own processing of requests, and no errors occur.

This update is relatively new, and many third-party backup applications do not support update 2 yet, which is why I have offered the workaround here.

One last note about Microsoft domain controllers and Vmware snapshot backups
In 2006 (revised in Dec. 2008), Microsoft released KB 888794 (http://support.microsoft.com/kb/888794/en-us), which states that

"Active Directory does not support any method that restores a snapshot of the operating system or the volume the operating system resides on. This kind of method causes an update sequence number (USN) rollback. When a USN rollback occurs, the replication partners of the incorrectly restored domain controller may have inconsistent objects in their Active Directory databases. In this situation, you cannot make these objects consistent. "

In reality, the BURFLAGS registry referred to in Microsoft KB290762 (http://support.microsoft.com/kb/290762) can be set so that the virtual DCs are nonauthoritative, and an existing domain controller can be set to authoritative. This will allow the USN to be overwritten by the authoritative domain controller, and no USN rollback will occur.

Labels: , , , , , , , , , , , ,