Kaspersky Install Error

Desktop Support, ,

I’ve decided to move us away from McAfee and onto Kaspersky.  I’ve used McAfee’s product here for more than ten years and have been pretty happy with it and it’s protection has been pretty top notch, too ‘top notch’ as a matter of fact.  I’ve in fact gotten away from even installing McAfee on mission critical systems due to it’s penchant for bringing systems to their knees at seemingly random intervals.  It had gotten to the point that I didn’t even see the point of paying for McAfee since I had so sparesly installed.

It was at that point I knew a change was required: a virus scanner barely wroks to begin with, but not at all if it’s not installed.  I’ve had a foul experience with Symantec (doesn’t seem to stop anything) and Trend (ditto, at least for their home product), so I decided to go with Kaspersky.

What was interesting though was when I first went to install it on a batch of PCs I got a bluescreen error on one of the PCs (my bosses system!) of 0x000000d1.

As it turned out though, the issue had nothing do to with Kaspersky, and everything to do with some bum DNS entries.  In my initial testing I was installing to two computers of users who weren’t in that day, but then my boss called and said that it was installing on hers.  I thought this was odd, but when I checked the logs Kaspersky did indeed say that I had installed it to the incorrect system.  Flustered, I ran it again while double checking the computer name (which is fairly similar), and around that time my bosses PC bluescreened and Kaspersky again said that I was installing to the wrong computer.  At that point I resolved that I would use the IP address of the computer I wanted to use, so I pinged it and plugged it into the script and as a joke before running it I pinged my bosses computer to see what it was, and it turned out that it was the same.  My desired target PC had the wrong address assigned to it in DNS.

Kaspersky proved rather extra adept since it detected the name failure and then helpfully replaced the ‘wrong’ name with the ‘right’ name that the system was reporting and the blue screen was caused by trying to force an install over the existing install.

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.