JDE OCX Files

Desktop Support,

For some reason I never thought to note a workaround that we use for our JD Edwards ‘ocx’ files, probably because I figured that no one would be running on a tools release as old as our own. Trying to run the export to Excel program and whatnot with newer versions of Internet Explorer can lead to errors like “This media object is not viewable on this type of browser” or the program flat out not executing.

The problem, as it turns out, is due to a browser check issue in the programs where they don’t know what to do if your browser is newer than ‘6’. The solution is for your browser to lie about what version it is. The first step is to download and install a ‘user agent’ picker, such as this one. The next step is within IE, go to Tools->Set UA String->and set it to ‘MSIE 6.0’. You can then load the addons, and after they load in the browser you can set the browser UA string back to the original setting.

UPDATE 12/5/2013: It appears that starting with IE 10 that UA picker will not work if you are not a local admin, which is the case for 99% of our systems.  The only work around that I’ve found for our particular situation is to have a hard setting in Group Policy that gets pushed down to the clients.  It would appear that IE 10 only pays attention to the UA setting in the “Version” key in the registry hive “HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent”.  The “Policies” hive, despite being in HKEY_CURRENT_USER, cannot be written to by the current user by default (thus any solution run by a user without elevated privileges will not work).  If you are running as a local admin, I did stew up my own program to change the registry key on demand (NO WARRANTY!): Source (VS 2010 project), Executable (.Net 2.0 required).  Remember, it’s required that the program be run as Administrator (right click->run as Admin).  You cannot run this as an admin apart from the account that you want changed (i.e. user1 is logged on, but right click->running it as user1admin) as the changes must take place in the profile of the ‘Current User’.

Christmas for Barracuda

email

Yes, ‘Christmas for Barracuda’, or ‘How high maintenance costs ruin a relationship’

So our Barracuda Spam Firewall cost around $2100 new, and to it’s credit it has worked rather well**.  However Barracuda is now charging us around $660 dollars for yearly maintenance?!  Really, more than of the 30% purchase price for maintenance?!  I don’t care what excuses they make, but this extortion level pricing is nothing more than a horrible mistreatment of their exiting customer base.

My advice at this point for those looking to buy such a solution is to look elsewhere, maybe to something that doesn’t have quite the vendor lock-in issue.

*Even though the GUI moves like molasses through a sieve and I’ve been waiting years for them to add the ‘auto power on’ ability to it so that I don’t have to go into work at two in the morning after a power outage just to turn the stupid thing on so that our e-mail will work.

Migrating from 32bit SharePoint Services

Server Support,

This is my definitive guide on migrating from 32 bit Windows SharePoint Services 3 to SharePoint Foundation 2010 (64 bit only, oof!).  It’s not quite as definitive as I would like as I barely had time to work this through once, let alone multiple times:

  1. I changed the user account that runs WSS3 from ‘NETWORK SERVICE’ to a domain account (though I’m unsure if this step is required).  I originally did this when trying to restore the 32bit WSS3 onto the 64bit box and then using 64bit WSS3 to try and upgrade it.  Don’t do that by the way.  Anyway it made working with the database easier on the whole anyway.
  2. Backed up the SharePoint content database, called STS_servername_1 in my case. (This server used the ‘Windows Internal Database’, an extra crippled version of the already crippled SQL express.  I had installed the SQL 2005 tools on there for a different project so I used the ‘SQL Server Configuration Manager’ to change the service argument to add “;-T7806” and I then used the SQL management studio to do the backup).
  3. Installed 64bit Sql Server 2008 express on the new 64 bit server (I named the main instance the same as the instance on the 32bit box, not sure if that matters)
  4. Installed SharePoint Foundation on the new 64 bit server (it automatically set itself up in the SQL instance I installed).
  5. Restored the content database to the new server (again, using the management studio; I know that it can be done through the command prompt but I like the visual feedback).
  6. Within the Central Administration site on the new server I went to ‘Manage Content Databases’, clicked on the preinstalled content database and removed it in the subsequent interface.  This step removes the content linked to ‘/’ so that the restored database can go there.
  7. Added the restored database to the farm using stsadm. (in our case: stsadm -o addcontentdb -databasename STS_servername_1 -databaseserver newserver-url http://newserver/)
  8. Upgraded the content database using the ‘upgrade-spcontentdatabase’ command within the Sharepoint PowerShell.
  9. The content should now show up when you pull up http://newserver/ , but to complete the upgrade (and keep the content database from showing as ‘mostly upgraded’ or something along those lines) I had to upgrade the view under ‘Site Settings’ within the Sharepoint site and then going to (I believe) ‘Visual Upgrade’.

Obviously our setup is fairly simple with one server driving the whole ‘stack’.  Our content is also fairly static (it didn’t matter that the database backup that I was working with was a day old).  Your results, of course, may vary (but will probably do a sight better than trying to put something together from the amalgamation of websites that only convey one piece of the puzzle!).

MAS Client Issue

Server Support

Part of my motivation for patching up the system was so that we would be running a version of MAS 90 that was officially supported on 64bit Windows 7.  An odd issue that’s possibly related to compatibility cropped up today though.

When going into one of our companies, MAS would crash/stop responding when going in to “reprint journals” under the general ledger reports.  It worked for every other company AND even worked for that same company if the report-program was run from a 32 bit system.

The big clue was that the UI for the report never launched after clicking OK for the accounting date, which usually tells me that an ‘output issue’ exists.  After comparing the settings under company maintenance it turned out that the one that didn’t work didn’t have “Use Workstation Default Printer for STANDARD Report Setting” or “Form Code” checked.  After checking those two boxes and accepting the changes “reprint journals” began working for 64 bit systems.

MAS 90 Patch Issue

Server Support

I recently decided to be brave and install a hotfix rollup/service pack to our MAS 90 4.3 install.  I believe we were on patch 3 and I would be installing patch 20.  My goal was to clear up some oddball Windows 7 issues that we were having (the exact nature of which I cannot recall unfortunately).

After installing the patch everything looked okay.  It appeared that the client upgrade was somewhat optional since it only upgraded the help files (though I did it anyway just to be sure), and when opening some of the companies in the database I got an unexpected upgrade notice (unexpected since the system was patched and not upgraded):

For all but one of the companys, getting this “Data files have not been converted for this company” message wasn’t an issue.  However for one of the companies in our database we would receive this error, go through ‘Company Maintenance’ to upgrade it, then receive a message that said that there was nothing to upgrade, but then get the “have not been converted” message again when trying to go into the database.

What was odd was that under ‘Company Maintenance’, the ‘Common Information’ module for the company was listed as version “4.09” (which so far as I know, wasn’t even a production release version of MAS 90).  Every other module in every other company was listed as “4.30”.  I am unsure as to how MAS works in the background, but when I looked at the files through a hex editor it did appear that they reporting that they were version “4.09” (however in hindsight it would appear that this value was ‘pushed in’ rather than ‘pulled out’ of the tables).  Ordinarily it would probably be worth restoring the data and trying to figure out what went wrong, but for reasons I’ll not get into the application had already been used for more than two weeks (outside of that company of course).

As luck would have it, I needed to perform some operating system tests a couple weeks earlier and had a test copy of the virtual server that hosts our MAS installation and the data was from before the upgrade.  I tried copying the tables over and a couple other little things, but after nothing worked out I decided to try and upgrade the test copy of the database to see why the upgrade to that company failed, only…it didn’t.  It worked fine.  I then copied over that copy of the company over to the production MAS.

What happened next was rather odd, but MAS is a bit of an odd product.  The version number was still reported as “4.09”, but in poking around I opened the ‘Copy’ utility under ‘Company Maintenance’ with the thought that I would copy another company’s ‘Common Information’ set over to see if the version stayed the same.  I thought better of it again (this wasn’t the first time I mulled it over) and I canceled out and then for whatever reason the version number for ‘Common Information’ was properly reported and the upgrade error went away.