Tuesday, June 16, 2009
It always seems like every time one thing if fixed, something else breaks. This morning I was working on Project A and I needed to look something up on our ISA 2006 firewall. While I was there I decided that I would look into, and fix, something odd that was happening with Project B's rule. Well, after fixing the rule into a corrupt state, I now had a Project C to work on as well. Corrupt rules are never fun, but I was able to figure out how to fix it, but I'm sure it's NOT a supported or recommended procedure.
When I was trying to find out exactly what machine we are routing FTP traffic, I wanted to take a look at why my IMAP connections seemed to be getting mail that was MONTHS out of date. Looking up and down the list of rules, I found a duplicate IMAP(S) rule that was pointing to an old IP address of our Exchange 2007 server. I figured that somehow, that might be a reason why I'm not getting the correct e-mail. I clocked into the rule, and changed the internal endpoint to our current Exchange 2010 server, clicked Apply and then OK.
On closing out of the ISA Management Console and looking at my e-mail, I noticed that my Inbox was starting to fill up with alerts from System Center: Operations Manager telling me that there was a problem with the configuration on one of our ISA machines, specifically the one that I was logged into. Side Note: I know I should have been looking at the configuration on the Configuration server, not one of the nodes of the array, but the Configuration server is having problems of its own!!!
Logging into the Configuration server, I opened up the Management Console and noticed that the rule I had edited was missing a bunch of information. Clicking on it (right or left) brought up an error dialog stating that "there is not enough memory to perform the action." After much fumbling and scrolling up and down, I realized that the name of the corrupt rule was the same as one farther down on the list, and when I changed the IP, the rules ended up being exactly the same. This led to the node pushing the change up to the configuration server before it was really sure that it SHOULD, and so, I am stuck with this dumb ghost rule. Since I know that I couldn't affect the corrupt rule, I decided to change the name of the good rule, so they wouldn't match! Brilliant!!! (:
Things weren't quite that simple, however, and when I made any changes to anything else on the server, I wasn't able to commit the changes! I kept getting an error that the corrupt rule needed more information before the changes could be saved. Oops! I even tried Exporting the rule set, removing the offending rule from the XML file, and then Importing it back in, but I ran into the same error.
It was time to bite the bullet and following the somewhat sparse directions from this forum post, I fired up ADAM ADSI Edit to remove the offending rule, once and for all.
Even though the directions weren't the best, it was enough for me to get there, so I'll post a little bit more coherent account:
NOTE: I am pretty sure this is NOT supported. Any time you mess with ANY of the raw editing tools, you stand a big chance of messing things up beyond recovery. DO NOT USE these steps if you are not willing to accept total failure as a possible case.
Wednesday, April 29, 2009
I've been working with Domino and Lotus for a fairly short amount of time, but every time I have to touch it, I find myself gritting my teeth. I've been a Microsoft Exchange admin for a while, but I have a bunch of experience with several different e-mail platforms. While I am not as familiar with many of them as I am with Exchange, I can set up systems, start e-mail flow, provision users and just generally get by. One of the things that helps me do this is the rich environment of help and documentation that exists out on the Internet. Sometimes the gems of wisdom lurk in forums, sometimes they are on a product's support site, but more often than not, someone else has run into the same problem that I am having. This makes me feel a lot more comfortable and at home with a product, when I know that other people are actually using it and willing to SHARE their experiences.
Well, IBM, you have earned my ire in a bad way!
The situation is that one of Domino 8.0.1 systems I'm managing needed to have Domino Web Access set up so that the end user didn't have to know the whole long URL to his or her mail database file. In Microsoft Exchange 2003, 2007, and now 2010, this is a built in feature that, for the most part, works out of the box. So long as the user is configured for Outlook Web Access, they just have to navigate to a website that was installed on the server by default, enter in valid credentials, and off we go.
This is not the case, however for Domino Web Access. By default, once the user is configured to use DWA, they have to type in an exact URL pointing to his or her specific mail database file. I had known this and just ignored it, since Domino didn't install with any web sites enabled as default, but the client wants people to be able to test the DWA experience without having to know that information. So began the journey (my Google searches):
"how to create a lotus notes login page"
"how to create a login page for DWA"
"how to create a login page for Domino web access"
Now, these searches didn't really net me anything useful, so I headed over to IBM's web site and went to the Documentation section to do some digging. After drilling down, I found this page with some helpful steps:
Setting up Domino Web Access Redirect
The Domino Web Access Redirect template (IWAREDIR.NTF) is in the Domino data directory. To set up Domino Web Access Redirect:
- Create an application using the IWAREDIR.NTF template.
- In the IBM® Lotus® Notes® client, open the application that you created.
- Click Setup and follow the prompts to set up Domino Web Access Redirect.
Note If you select MailServer as the Redirection Type under Server Settings, the common name of the Domino mail server must be the same as its fully-qualified TCP/IP domain name. For example, if the mail server field in the Person document is set to serverA/domainA, the server's TCP/IP fully-qualified domain name must be serverA.lotus.com.
Now, I have to say, this was a WTF moment. Once more, I know that I'm not an expert, but I like to think that I can figure things out. This set of instructions, however, left something to be desired. After poking around on the server, I found the template, and with a right-click, I found that "New..." wasn't an option. How am I supposed to create an application?!?!? More Googleing:
"lotus domino create new application from template"
"lotus domino create new application template"
Which led me to this page with some more detailed instructions on completing the FIRST step in the previous set of instructions:
1. Open the Notes client.
2. Choose File-Application-New. The New Application box appears.
3. In the New Application box, select the Blank Composite Application template from the Template list.
4. Enter a title in the Title field. The File name is also created for you from your title. You may change the file name if you wish.
5. Click OK. A blank composite application container appears with a message that the application does not have any content
6. Choose Action-Edit Application to open the Composite Application Editor and begin working on your composite application. You can use the Composite Application Editor to edit the pages, components, and basic properties of a composite application
This set of instructions is not perfect, but I can steal at least the first two, verbatim, and then monkey around with the settings until I manage to create the new application! Woo! Now I'm getting somewhere...
Thursday, April 16, 2009
Basic Overview
Now that Exchange 2010 has been released to beta, it's now time to talk about all the fun things that we've been working on and working with. To start off with, I want to point everyone over to the actual Exchange 2010 Official site.
Now that I've pointed you at the bits, let's get into some details about Database Availability Groups or "The DAG" as it's called! To start off with, it's a pretty simple concept. The DAG uses Windows Failover Clustering Services and a NEW component in Microsoft Exchange, called Active Manager, to allow automatic failover and uses continuous replication to keep copies of a Mailbox database floating on servers other than the one actually hosting the "active" copy. This is VERY simplistic, but I want to gloss over the details for a moment to build up to the details later. What this means is that now, we can host a bunch of copies of a Mailbox database on several servers (up to 16 servers can be in one DAG) and thanks to the magic of continuous replication, the log files are shipped and we can have multiple, concurrent copies of the database. In the event of a failure, Exchange 2010 "promotes" one of the copies of the database to "active" status and the Mailbox role then takes up the task of serving up the mailboxes on that database. Each database maintains separate status, so one server can host copies of multiple databases and only have some of those copies active at one time. This can be confusing, so let's draw a diagram (ooo, pictures!):
In this diagram, we have three servers, and three copies of each database, one on each server. The "active" database copy is the one with the star. The flow of data from the "active" copy to the "passive" copies is concurrent.
Hopefully, it's clear that a copy of each Mailbox database is hosted on two other servers in this scenario. There are actually several reasons for this, and let's start talking about some cases. In the first one, let's say that we lose MBDB01. In this case, it's just a simple failover and the next preferred server will elevate and start hosting the mailboxes (and for those of you wondering, YES you can set the preferred failover scheme, for example, if you want it to go 1, 3, 2 instead of 1, 2, 3, you can set that). That is a pretty simple case, why else would you want so many copies? In this case, we could use this type of architecture to fail a server, apply patches, and avoid nasty maintenance downtime, but will still be protected if one of the other servers fails during that time. Good 'ole double redundancy. The third case for maintaining at least three copies is that ensures that there are always enough servers in the DAG, up and running, to allow a quorum for the underlying cluster.
All of the mailboxes are hosted on one server, BUT, you are still able to have users access their e-mail, without long, expensive restores or complicated reconfiguration of your DNS or network!
How it actually works
Earlier on, I mentioned that the DAG uses Windows Failover Clustering and continuous replication to build the copies of the database. What is actually happening is (to me at least) much more interesting. The Windows Failover Clustering service is installed just for the purposes of the automatic failover. The way the databases are treated and how they are handled it much like the Exchange 2007 features of CCR with a few of the SCR features thrown in for good measure. One of the big differences between the DAG and CCR is that you can configure the number of database copies which allows you to make full use of the Clustering components. One of the reasons why I used the three server example, above, is because this is what Microsoft has recommended for the cluster to properly determine quorum decisions. You can get by with only two copies, but at least three is the recommended minimum.
One of the great features of using a DAG is that it is completely managed from Exchange. What this means is that when you are configuring the clustering you don't have to be a clustering wizard or HA guru to set it up correctly. Exchange 2010 takes care of all the configuration for you, and as my co-worker Devin says, this is a HUGE win.
What people are saying and doing
All this talk about clustering and data redundancy brings up an interesting conversation that is currently floating around, and that is, with a sufficiently robust DAG structure, do you still have a need for on-site backups? This has opened up a whole can of worms, and I can say that I feel confident that using a properly designed DAG scheme can easily replace many of the functions of standard backups. There are still areas that I would feel more comfortable with a reliable set of backups (database corruption or total site failure), but the DAG can mitigate some of the risks.
That being said, the way that we currently are using our DAG is a little bit different than the scenario I laid out above. To get even more complicated, I have plans to modify our structure to take advantage of Network Load Balancing and turning our current structure into one that it aimed at a high amount of availability! Here's the planned structure:
In this particular case, the plan is to basically mirror the servers using NLB to serve up one logical endpoint for the CAS, HT and UM roles (with the Hub Transport have to be careful to exclude the HT to HT traffic from the NLB, but that's a topic for another post). With that in place, and using the DAG to take care of two copies of a single database, we expand our ability to perform maintenance with minimal downtime to our internal clients while also providing a high amount of uptime in the case of a failure.
EDIT: It looks like, according to Microsoft, the combination of Windows Failover Clustering and Network Load Balancing is NOT SUPPORTED. They also say that it won't work, but I want to give it a try, anyway. This is a big pain since for a small to medium size business, you want to reduce the number of servers you have. This is what the documentation actually has to say:
Unlike Exchange 2007, where clustered mailbox servers required dedicated hardware, Mailbox servers in a DAG can host other Exchange roles (Client Access, Hub Transport, Unified Messaging), providing full redundancy of Exchange services and data with just two servers.
So, now I've talked about the DAG and what it can do, but there is quite a bit more. I'll follow this up shortly with some more advanced features like lag copies, off-site replication and other fun things!
Tuesday, March 03, 2009
With all the nifty features and functions that are available in the new version of OCS, I can't really see a reason to hold back and NOT migrate. Being the type of company that we are, it's important to keep up with the latest products and show that we can make them work. That being said, sometimes it's hard to hit the ground running when you don't have a large customer base for that type of work.
One of the struggles with any small company is that with the limited resources available, sometimes you can't set up a whole new lab environment just to test the new software. In my case, my work on other paying projects put a lot of internal IT projects on hold. This is not to say that the projects were being ignored, just that they took a much lower priority than I would have liked to assigned them.
My current project of love and devotion is our migration as a company to Office Communications Server 2007 R2, which was recently released. This is a big deal to me, being a Unified Communications consultant, so I've taken the time at work and at home to learn about what needs to be done.
I don't want to sit here and outline all the dinky step-by-step screen shots, since I'm sure that there are other sites out there that have those. What I'd rather do is outline the thought process and planning steps that are required for the migration.
Okay, on to the fun stuff... Let's talk about migration paths!
Supported Migration Paths
Microsoft has put a bunch of OCS 2007 R2 documentation on Technet, but none of it is available for download, so I'll just sum up some of the recommendations and provide the link so that you can get more detail about them on the site. Oh, wait... There isn't any more detail!
To start off with, there are two supported upgrade or migration paths:
- Side-by-side migration
- Uninstall/reinstall
Side-by-side Migration
This is the one that sounded like a really good idea for us, due to my limited time to ensure that everything was set up correctly. In this scenario, you stand up a second pool in the same Forest and then migrate users at your leisure.
Pros:
- You have the ability to deploy the environment and validate/test it before you deploy it
- It could be done with minimal downtime for users, theoretically no loss of service
- Pool co-existence allows for cross communication and migration
Uninstall/reinstall
For this install, the process is dead simple. You remove all the old stuff, and you install the new stuff. Of course, there are more steps to it than that, but the idea is pretty simple. I didn't think that this would be a good fit for us because of the downtime that would be incurred. Okay, who am I kidding? I didn't want to take the time to listen to people complain about downtime. I think we, as a company, could handle it
Pros:
- It minimizes the use of extra hardware (rebuild on the same platform)
- The installation is simplified when dealing with back ends (more on this in the details)
- This is a good chance to completely rebuild and redesign your OCS infrastructure
The Devil is in the Details
When the dust settles, it's all comes down to what actually the details of the situation are. In the case of migrating any production system from one version to another, there are going to be a host of issues and minor settings that can either slip through the cracks, or come back to bite you, later. The details always start out as a high level overview and then drill down to individual check boxes and radio buttons.
In Part 2, I'll cover the details of the Side-by-side Migration and in Part 3 I'll cover the Uninstall/reinstall details. More to follow!
Wednesday, January 28, 2009
So many of the posts I put up are informational in that I found out something that I want to be able to find if it happens again. This post isn't much different.
Here at 3Sharp, we use the blogging platform Subtext. It's not my favorite platform in the world, but I understand the reasons why we use it. That being said, I'm going to get to the meat of this post. First up, posting using applications other than the web console. To post to Subtext, you have to make sure to use the right provider. With Subtext, that's MetaWebBlog.
Once you've set that, the URL that has to be entered to post is:
http://<blog URL>/<User Name>/services/MetaBlogAPI.aspx
This wasn't exactly hard to find; it seems lots of people want to try to connect to it using blog clients. I just want to make sure that I have the information handy when co-workers ask, "how do I use this thingy again?"
Tuesday, December 23, 2008
Woo! Now I can talk about it! It looks like Office Communications Server 2007 R2 has been officially blessed and released to manufacturer (RTM)! Once I get my grubby little hands on it, I'll be posting pictures and how I have things set up, but I wanted to mention a couple of things that are key (to me) in this release:
- 64-bit only
- Officially supported on Server 2008
- Simplified Edge role management and existence
Management improvements
- Additions to the MMC snap in to support new features (Conference Attendant, Application Sharing, etc..)
- Administrative tools now have a separate install (I can put them on my remote workstation)
- Automatic and Push updates to ALL devices (Roundtable, Phone Edition, OC 2007 R2)
- Improved Certificate Wizard and Management (I haven't seen this yet, but it is my favorite on paper)
Now that I have that little list, I can start to go through the Planning and Architecture and build a NEW OCS design based on the new goodies. I'll post a diagram as soon as I have it ready.
Thursday, December 11, 2008
You name it and OCS can do it. I know that might be reaching a bit, but I've been looking into the new features that R2 will bring to the table, and it is really quite impressive. I've been working with OCS 2007 for about a year now, and while I've been impressed, there are some cases where I've had to say, "well, OCS really isn't a product for that arrangement," or, "it's still early in the product life-cycle, it'll get better." Now, most of those phrases are going to go away and will be replaced with comments like, "yes, OCS can do that, and that, too."
This is by no means an exhaustive list, but this is a quick start of the things to come with the new release. I garnished these points from watching a video here. There are a bunch more OCS 2007 R2 videos, and I can't wait until it hits RTM so I can install and play with it!
Friday, December 12, 2008
This is an information post, designed to make some information available to myself and others. I did NOT discover this but I thought it was something pretty important.
When disabling an Exchange 2007 mailbox, it sometimes will not automatically show up in the "Recipient Configuration | Disconnected Mailbox" bucket. It takes running the command:
clean-mailboxdatabase <mailbox database>
Once that command is run, you can reconnect it or do whatever you need to it. Thanks Missy and Amit (If you want the full explanation and pictures, click here)!
Well, after a bit of time spent on Microsoft's campus, I have 8 Tanjay devices with the latest and greatest firmware. I used a Tanjay device (a Polycom CX700 IP Phone) for a number of months, and while I didn't have a ton of voice communications with it, I loved the ones I had. There are a few complaints that I have about the device, but they deal more with the form-factor than functionality. What I wanted to note was something more tangible (pun intended) than complaints. What I wanted to mention is a reminder that the Tanjay devices are Enterprise Voice extensions. They are devices that are supposed to sit on your desk and replace that silly little phone you have there with a Office Communicator client that provides the rich client experience that OCS 2007 is supposed to provide.
What does this mean to the average Joe User? Well, to give a real-life example, I was just talking about how I have 8 devices with hot-off-the-press firmware and a desire to get them up and running. Even before my co-worker and I went to Microsoft to get the update, we were having a debate about why his devices were not able to connect earlier today. After banging the issues about for a while, he was convinced that it was a certificate issue. I was a little bit more skeptical, simply for the fact that it didn't "feel" right. I was willing to come back to the office later, with the upgraded devices and look into it.
After trying to log in with the fresh devices, I was willing to admit that something was wrong. After poking around, I found that in some cases, autoenrollment of domain users and devices was disabled, and so I enabled it using GPO. Thinking hard about it, what this does is tells a device that is logging in with a domain account that it's okay to request a certificate from the domain CA and where that CA is. Sadly (at least for Devin), this didn't correct the issue. I sat and thought about it while I worked on something else, and when I finished with that, I decided to start back at square one and walk through setting up a Tanjay device for the first time. A quick web search and I ran across the problem (I didn't really "run across it.." It was more of a "the answer slapped me in the face and called me stupid"). Reading this post on a blog, I noticed that you have to enable the user for Enterprise Voice. Right now, we switched all of our users to Remote Call Control so we could use the connection with our Mitel 3300 ICP phone PBX.
Long story short, now our users have a choice between a Tanjay device and RCC. This is actually kind of a tough one for me, since I really like how RCC keeps track of my phone communications. I've been having trouble with some phone companies, and having the automatic tracking of who I call when is really helpful. I'll just have to see how things play out once I build our new OCS environment.
Wednesday, October 29, 2008
So, there's been all this hooplah (created by me) about the MacBook Pro that I'm using at the moment. I have been really enjoying my time spent with it, and I've been able to overlook some of the minor issues that I've run into. I do wish that it had more RAM. I do wish that Excel could open my timesheet. I do wish that I could easily sync offline files (Paul tipped me on a product, but I don't want to write about it until I've fully tested it).
Those are all small issues, but what I've run into now is bigger than that. Apparently, I am running a 32 bit operating system <pausing for the collective gasps>! I made the attempt to create a new virtual machine running Windows Server 2008, so that I could run a couple of the management tools that I can't run in OSX. My attempt resulted in this screen:
Shocking, I know. Now, I also understand that with a smaller amount of RAM in my system, it's really not a big deal to not have all 64 bits of addressable space, but the outrage is justified. In doing some research, I found out that the chip that was shipped was 64 bit CAPABLE, just not ENABLED. I'm not going to futz around and try and make it work, but that is something that I want to make sure my next hardware purchase can handle. I know this sounds silly, but I try to research these things, and I've walked away from buying hardware because it lacked a single feature that I wanted. NOTE: This should be taken with a hearty understanding that a) this is a WORK laptop and that I didn't pay for it and b) I am very grateful for the chance to use it and experience the goodness that is a MacBook Pro.
That all being said, I'm off to dig up my 32 bit version of Windows Server 2008 to install. Whee!