June 2005 Archives

Just attended the 6/29/05 meeting (w/ Ag Ed, EIT, Ag Comm) to discuss "the potential of creating a collaborative focused on the development and delivery of internet and other distance education products." (quoted from Larry's 6/21/05 email). Here's what I think I heard, just for the sake of documentation:

1. The idea: Distance Education - as a topic encompassing such things as web presence, eLearning, ePublishing, marketing, etc - is broader than the skillset any of any of the three individual groups. As a result, (a) customer groups within the organization often don't know who to contact for help, (b) any help that's provided is likely to conform only to the immediate needs of the customer, often (c) without any consistency or linkage to Extension as a whole and (d) without including the skills of the group(s) NOT involved. Thus, a collaborative umbrella approach might offer a more systematic, inclusive way of addressing customer problems and would also provide an entry point for customers needing this kind of help. Further, it might eliminate some of the "Lone Ranger" approaches to solving problems.
   
2. Would likely be managed by a coordinating board of some kind.
   
3. Per Ellen Ritter, the focus of this group would be more strategic in nature (as opposed to "action-oriented" or tactical). I'm not sure what this means since a strategic approach is, to me, a broad set of objectives or guidelines (low level of detail). A project would still have to be accomplished by a working group (high level of detail) which might be led by an individual from another unit. Ellen said as much. (But if the coordinating board is concerned with strategic issues, then who decides who will participate in a joint project or what the priorities are? Does this mean a second group - like a screening committee - would be involved?)
   
4. Rather than this being an exploratory meeting, it came across more as a done deal. In fact, Scott pointedly said that the three unit heads are 100 percent behind the idea and have already sold Margaret Hale on the idea.
   
5. Next action: People in attendance were asked to give some thought to volunteering to be part of an advisory group to put together some specific recommendations on how to proceed further to make this become a reality, and to notify their unit heads if they wish to do so.
   

Some observations & questions:

1. What other alternatives have been investigated? We have a management structure already in place; why couldn't those managers develop their own working relationship - formally or informally - to address this problem? What will this collaboration accomplish that our managers can't?
   
2. This approach is essentially the introduction of a set of rules. If rules are to be effective, they have to be enforced. How's that going to work? Will we periodically need to list all our projects and pass them by the screening committee to see how they measure up against the rules? Will this have the effect of stifling initiative?
   
3. If a customer calls me directly and I can help him, I'll do it if there's a way. If I can't, then he'll call someone else - maybe Larry, maybe whoever. I think that approach would still be the case even if there's this so-called "entry point". People will call whoever can give them results. If/when they conclude that going through the screening committee simply slows down their projects, they'll find another approach. And nothing will have changed.
   

I can see something like this working if it's kept low-key and relatively informal. If it becomes bureaucratic and cumbersome, though, it'll just be another committee.

Back in the "old days", the powers-that-be decided that WordStar, dBase and SuperCalc (spreadsheet) were going to comprise the official Extension software suite. An Ag Economist, of all people, decided that a spreadsheet called Lotus 1-2-3 was his preference. A lot of people agreed with him. Maybe there's a moral in there somewhere.

~ja

Not that many of us will need this, but I just went through it & wanted to document the steps.

Objective: Make a console application run as an NT Service on a W2k box. Reason: I want the app to be reachable & "alive" whether I'm logged in or not.

Steps involved are as follows:

1. Two MS programs are needed: INSTSRV.EXE and SRVANY.EXE. These are included with some of the older Resource Kits but are also, I believe, available on the net. INSTSRV.EXE is the actual service installer while SRVANY.EXE is a "wrapper" that actually is installed as the service and which is what executes your application.
   
2. Install both programs in either the \System32 directory or the directory where your app resides. In my case: c:\Mercury.
   
3. Be sure the login you're using has administrator privs and that your app is NOT running.
   
4. Open a Command Prompt window (aka a "DOS Window" for those over .. whatever). If you've copied the two programs above into your app directory, navigate to that directory. If the two files are in \System32, any prompt will do.
   
5. At the prompt, install SRVANY.EXE as a service using INSTSRV.EXE by entering the following:
   C:\>instsrv YourAppName "PathToYourApp\srvany.exe"
   In my case, the command line entry is:
   instsrv Mercury "c:\mercury\srvany.exe"
   
6. You should now see a response along the lines of "CreateService SUCCESS".
   
7. Verify that your service got added by bringing up your Services applet. In W2k server, it's Control Panel->Administrative Tools->Services.
   
8. Configure the service to start however you wish (Automatic or Manual). Set it to log on as a System Account.
   
9. We're almost done but not quite. If srvany.exe were started as a service, it wouldn't know what to execute. Notice that we haven't said anything about the name of the actual application (c:\mercury\mercury.exe) anywhere above.
   
10. Run regedt32.exe (located in the \system32 directory) and navigate to HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services and double-click on the "YourAppName" service entered in step 5 above.
    
11. Click on the Edit pulldown and select 'Add key' and create a 'Parameters' key.
    
12. Open the 'Parameters' key and add a string value called "Application" (REG_SZ).
    
13. Edit "Application" and enter the path to your application (for me, c:\mercury\mercury.exe).
    
14. Exit regedt32.exe and, in Services (step 7 above), start your application.
    

FWIW, another way to start/stop the application: Use the MS Net.exe utility from the command line, as in NET START YourAppName and NET STOP YourAppName. This approach is helpful if you use telnet to access your machine remotely.

~ja