Non-Technical Wonderings: Teaching and Groups

I remember in my Undergraduate Programs how much I hated group work. Your group wasn't always in sync with you, and sometimes interpersonal communication became a royal issue. Of course, an instructor was trying to teach you to have the ability to work together, because sometimes (i.e., the real world) you have to work with people that you don't like, or that aren't as capable as you.

When I completed my Graduate Program, I realized how much I loved the group work. Maybe it's because everyone felt they had to be there as an Undergrad, but those in the Graduate program actually wanted to be there. They were, on the whole, willing to put forth the effort to do what was needed to be done. And as a group of working adults, you could communicate with each other, and figure out what you needed to have done in a timely manner.

Now, speaking as an Instructor for an Undergraduate Program, I still want to do Group Work as relevant for the reasons I've mentioned above. But it's difficult to see a group have some failures because of minor shortcomings that get overlooked due to those interpersonal issues. Every single person misses a question because one person didn't do the task accordingly. There's something to be said in group failures and group successes, but, I don't know that I agree with the idea that a group should have issues because one person makes a minor mistake. But to rectify that, every member of the group should be looking over each other for mistakes. Again, that's the idea of group work.

I suppose it's a mixture of having the available resources to accomplish a task, versus making group coordination and communication a part of that task. I suppose I've always appreciated the idea of group work, but in practicality with a time crunch involved, I wonder if it's feasible.

Cisco ACS Migration 4.2.x to 5.6, continued

Well, hopefully you'll read this post before you start your own journey through the migration process. Because it'll save you a lot of time. This posting might be a bit more 'ranty' than it is technically helpful, but I've been working through a lot for the past few days. I'll still include valuable links where available.

In the last posting I made, I provided information, links, and possible components that you should consider when making the migration from ACS 4.x to 5.6.

Let's catch you up on where I am.

After obtaining console access to the Windows Virtual Machine, the migration utility still refused to run correctly. After doing some more digging, I found this piece of documentation regarding the migration utility for ACS 5.6, notably this piece:

The ACS 5.6 migration utility is not supported on Windows 2008 64 bit.

Well. Grand.

After doing a bit more research, I found that ACS 5.4 and ACS 5.5 have no such warnings about their migration utilities. So now, we take the ACS Appliance that we have, and attempt to downgrade it from ACS 5.6 to 5.4. Except that in this documentation and in this documentation (and trial and error), you cannot install ACS 5.4 on the 3495 Apppliance. So now, we move on to ACS 5.5, which is supported on the 3495.

So now, back to where we have been originally. Re-download the migration utility from ACS 5.5, make sure to configure the ACS unit for the web-based migration utility (see previous post), connect to the console of the Windows 2008 x64 Virtual Machine, and attempt to connect.

You can probably tell from my enthusiasm that it didn't work. Which, at that point, I've exhausted every forum post and blog post relevant to this process, so, we turn to the Cisco support forums:

CSCtn17779 Bug was noticed, Run the migration machine on Windows 2003 32-bit.

And there you have it. I don't have access to a Server 2003 x86 server, so I can't test the validity of the statement.

Cisco ACS Migration, 4.2.x to 5.6

So it's been a while since I've written anything, and that's mostly because the majority of things I work on are now considered classified, internal, or confidential. It makes it difficult to write topics on concepts when you're not 100% certain the public can know anything about it.

This however, I'm relatively certain I'm good to work with.

So the company that I'm working with now is in the process of migrating some of their ACS servers from 4.2.x appliances to 5.6 appliances. Cisco has a pretty comprehensive guide on the process here.  One of the major issues that comes from 4.2.x on an appliance versus a Windows server comes from the fact that you need an NT Agent on a Domain Member server so that it can connect to Active Directory accordingly. On a Windows Server, the NT Agent is local, so it's not a worry. Well, Secure ACS 5.6 no longer needs that Windows NT Agent, it can just point directly at the LDAP server--great!

Except that we also have another major issue by having appliances. In order to migrate the database from 4.2.x to 5.6, you must first export the database from the appliance to a Windows Server, so that you can run the migration tool against it.

Which means that to migrate, you'll need:

• Your source ACS Appliance
• Your Windows Server to host the ACS Application
• A Windows version of ACS
• Your 5.x Appliance or Virtual Machine
• A series of helpful web links

Which is one of the reasons we have this blog post, is to provide a series of helpful web links, and share some of my infuriating issues.

Most of everything comes from this link, the Migration guide from ACS 4.x to 5.6. You'll also want to know how to re-image the appliance in the event that you blow it up.

Now, Cisco offers a full version of ACS 4.2 that's a trial to download, so as long as you have a support contract you'll be fine there.

This leaves you needing a Windows Host to run the software on. And...according to our documentation, ACS 4.2 runs on Windows Server 2008 x64. Note: Not R2. This was a huge problem in our environment, because their bare minimum standard for Windows Servers was Server 2k8R2. And because it's larger corporate politics, that meant lots of paperwork, lots of documentation, lots of justification, and someone's time to spin off a new Virtual Machine for me.

While waiting on the Virtual Machine spin-up, it's a good time to bring online the ACS Appliance for 5.6. Important note that I discovered during installation: the NTP server (or it was the gateway) must be reachable while loading the IP settings, or else you'll have to re-image it from scratch. Not sure why, but that's what I had to end up doing.

Once you have your ACS 5.6 appliance or virtual machine running, complete with remote accessibility, you can begin your migration. After waiting for your Windows Server to be built, loaded with Java, and imported from a backup, you're ready to begin.

First, download the migration utility from the ACS Appliance and load it on your Windows Server.

Next, when connecting, specify a username and password and connect accordingly.

Then, after troubleshooting the connections and available configuration settings, spend several hours tearing your hair out trying to further troubleshoot why the connection continues to fail for no reason. Then you find an obscure post on a German Cisco forum that leads you to this link. The point of reference that made me nearly scream was this:

Remote Desktop Support
The Migration Utility does not support Remote Desktop Connection. You must run the Migration Utility on the migration machine; or, use VNC to connect to the migration machine.

 So make sure when trying to run the migration utility, you don't RDP into your Virtual Machine. You have to VNC into it, or get some local hardware to run it off of.

Edit: On to the next issue....(You'll want to read that post if you haven't already)