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.