« March 2005 | Main | May 2005 »
April 29, 2005
Copernic Desktop Search Engine
I few weeks ago I downloaded and installed the Copernic Desktop Search Engine. I will say that I’m very pleased with it.
I had previously used the Google one, but was unhappy that it would not search files on my server. I keep all important files on my server as it get backed up every night.
The Copernic engine allows me to specify which folders I want to index and later search. I am particularly pleased with its ability to search my Outlook emails.
I have about 20 folders in my Outlook that I route mail to. I don’t delete a lot of email. I have every Microsoft Great Plains tech support incident I ever had in my Outlook.
If I run into a problem that I think I have spoken to tech support before, I just pull up Copernic, specify the tech support folder and type in a word or two. It takes less than one second to find the relevant entries. Outlook’s search takes a lot longer.
The other day someone was asking for some documentation for a project we did with them in 1999. Using the Copernic search engine, I found the documents in about two minutes.
I am very pleased.
Posted by Ted at 09:37 AM | Comments (0)
April 28, 2005
Some news about Microsoft Great Plains 8.5
Microsoft Great Plains is expected to release version 8.5 in October of this year. I’ve just found a couple of technical tidbits about it.
There will be only two upgrade paths to version 8.5. You can upgrade directly to 8.5 from either version 8.0 or 7.5. If you are running a lesser version than 7.5, you’ll need to upgrade to 7.5 first and then move to 8.5.
Microsoft Great Plains 8.5 will also support Microsoft SQL Sever 2000 and SQL Server 2005. Support for SQL Server 7 will be dropped.
Posted by Ted at 04:02 PM | Comments (0)
Is your Spam filter too agressive?
Information Week has a post relating that 42 percent of surveyed workers missed a deadline because their spam filter prevented them from seeing an important message. To wit:
The Infosecurity Europe conference partnered with Mirapoint, a Sunnyvale, Calif.-based vendor of e-mail server and security appliances for the survey, which noted that 42 percent of U.K. workers said they'd missed a deadline due to an e-mail message gone astray.
Two-thirds of them said that legitimate messages they should have received were blocked by their company's spam filter; two thirds of that number said the problem happened on a monthly basis, but a quarter said it occurred every week.
"The spam hysteria of the last few years has created the impression that blocking unwanted e-mail is the primary concern for businesses, with the result that some service providers and companies appear to have lost sight of their users' real needs," said Nigel Brooke, a vice president with the European office of Mirapoint, in a statement.
"Filtering unwanted messages ultimately serves no purpose if it undermines the effectiveness of the overall message network's responsiveness," he added.
Posted by Ted at 08:16 AM | Comments (0)
April 27, 2005
Additional Users Promotion
Microsoft has a promotion in play that gives a discount if you want to add more users to your Microsoft Great Plains. Here is the discount schedule.
- 1 additional user, 10% off
- 2 additional users, 15% off
- 3 or more additional users, 20% off
To get the list price just click either link on the left. Remember to add the 16% enhancement plan. That is always calculated from the list price. Microsoft never discounts the enhancement plan.
This offer expires May 20, 2005. As always, you must be current on your enhancement plan to take advantage of this offer.
As a reminder, you may also need to add more SQL users too. You must have at least as many SQL users as you do Great Plains users.
Posted by Ted at 04:46 PM | Comments (0)
Client Upgrade Complete
My Microsoft Great Plains client upgrade project is complete – for now. Last Sunday I finished the data conversion. Monday went on site and rolled out the installation to all the stations.
My biggest challenge was the custom application for their business. I had to move it from Pervasive to SQL. The programmer extracted the data from the Pervasive file to a CSV (Comma Separated Values) file.
It turns out there was some duplicate data in the file that I had to find and eliminate. That was a rather painstaking process, but once complete I was able to DTS the data right into SQL.
There was the usual task of modifying everyone’s desktop to their liking and I have to recreate the Purchase Order and one Invoice format. All in all, it went about as expected and the client seems pleased with the result.
I’ll be stopping back next week during their month-end to make sure that process runs smoothly.
Posted by Ted at 12:26 PM | Comments (2)
April 24, 2005
Item Number Change Done
I finished the client project to change some 4,500 of their item numbers. It ran somewhat slower than I had anticipated. I started it about 10:00 Saturday morning. It appeared to finish some time after 17:00 Sunday afternoon.
I think the reason it takes so long is it changes all the history tables. It's as if the previous item number never existed.
Posted by Ted at 06:55 PM | Comments (0)
April 23, 2005
Changing Inventory Item Numbers
I’m running a data change for another client. In this case they want to change some of their inventory Item Numbers. Microsoft Great Plains has a tool one can purchase for that and I am using it.
We’re changing about 4500 item numbers. I have an Excel spreadsheet with two columns, Old Item Number, New Item Number. I have saved that as a Tab-Delimited file and have fed that file to the Item Number Changer tool.
Now it’s just a matter of waiting for it to be done.
Posted by Ted at 10:46 AM | Comments (0)
Client Upgrade Continuation
I ran all the maintenance and reconciles on the client’s data last night. Then I started the Pervasive to Microsoft SQL migration.
This morning it was complete. I ran check links and it came through pretty good. Since it’s still in version 7.0 and I have no reg keys for that I could not compare report totals to previous version.
I have started the 7.0 to 8.0 upgrade. The client has a pretty nice server (Dual Xeon with RAID 5 SCSI hard drives). They have 2GB of RAM, but I have limited how much SQL can use so it doesn’t steal from the operating system.
The upgrade shouldn’t take more than a couple of hours.
Posted by Ted at 10:41 AM
April 22, 2005
Client Upgrade this Weekend
This weekend I’m doing a Microsoft Great Plains client upgrade. I’m upgrading them from version 7.0 on Pervasive to 8.0 on SQL Server.
I have a Remote Desktop connection to their server, so I can easily do this all from home. Much of the work is to just start something running, then check in periodically, and see if it’s done. Then repeat this process until the project is complete.
Posted by Ted at 08:02 PM
Microsoft Great Plains Price Lists Updated
I just downloaded and update the Microsoft Great Plains prices lists. You can view them by clicking on either of the two links in the left panel.
I have no idea what is different from the previous prices list, but now they are current.
However, the caveat remains, use them for estimating purposes only. If you want a quote, please contact me so I can clear any number with Microsoft.
Posted by Ted at 03:46 PM
Microsoft releases Updated Windows
Information Week has a post about Microsoft releasing 64-bit versions of its Windows 2003 and Windows XP operating systems. These updated operating systems will support the new processors being released from Intel and AMD.
The new operating systems will boost virtual memory capacity from 4GB to 16 Terabytes (16,000 GB).
I’m not sure how this will affect Microsoft Great Plains. My experience with Microsoft Great Plains is that one of the very large determining factor for performance is how fast you can get data on and off the hard drive. I don’t see how this will address that issue.
Posted by Ted at 01:51 PM
April 21, 2005
Notes from my Microsoft Meeting
I've been trying to translate what was covered at the Microsoft Business Solutions meeting into words that you would understand. I'm finding that rather difficult as they paint is such broad brushes that when they're done, I say to myself, "What did he just say?"
The speaker was Satya Nadella. He’s one of the Vice Presidents at Microsoft Business Solutions. I don’t totally understand their corporate structure so I can’t be more specific than that. He struck as a more technically savvy person than you usually find at that level. This was a talk he had obviously given before.
He said that Microsoft was reaching for “Affordable Adaptability”. He said there are three pillars to this.
- Low Cost
- Rich Functionality
- High Adaptability
I wish I could flesh out these points in more detail for you, but it’s difficult. Low cost is in the eyes of the beholder. But to that point, I will tell you, I have see the cost of Microsoft Great Plains drop quite a bit over the last three or four years.
Rich Functionality means they plan to give you a lot of things the software can do.
High adaptability means they plan on making the software a flexible as possible so that you can mold it to your business.
He said they plan on keeping a rich stable of third party developers to extend what Great Plains can do.
In summary I would say that over the last few years Microsoft Great Plains has declined in price while they’ve added more features and power to the software. Many, if not most, of those features have come from third party developers. Microsoft has seen fit to purchase those products and include them with the product.
In many cases those are now separate modules which you must buy. In other cases, for those users that have remained current on their enhancement plans, those new products have been included in the clients’ software at no additional charge.
I'll have more for you later.
Posted by Ted at 10:31 AM
Windows 2003 Service Pack 1
Information Week has an article about Service Pack 1 for Windows 2003 Server. The upshot is it breaks 14 software applications – by Microsoft’s count. One of the applications it breaks is Exchange Server 2003. That’s not good.
Ignorance being bliss, I downloaded and installed SP1 on my own server. I had no problems, but I’m not running Exchange – at least not at the moment.
I guess the moral of this story is review the list of known conflicts before you install it. Click here for Microsoft’s testing results.
Posted by Ted at 10:25 AM
April 19, 2005
Version 8.5 due in October
I was at a Microsoft Business Solutions meeting this afternoon. The speaker was Satya Nadella, one of the Microsoft Business Solutions Vice Presidents.
As time goes on, I'll try to translate what he said into words that we can all understand and pass them on to you. But I can give you this little tidbit.
Microsoft Great Plains 8.5 ships in October 2005.
Posted by Ted at 07:50 PM
Just How Old is XP?
I turns out that Windows XP was introduced almost four years ago. The next version, code names Longhorn, is not due out until late 2006. Is is just me or does that seem like a very long time between versions?
Posted by Ted at 08:33 AM
April 15, 2005
Longhorn Update
Information Week has a report on the next version of Windows - Code named "Longhorn". It will be a 64-bit operating system. It is due out the second half of 2006. Just click on the link to read the article.
Posted by Ted at 04:46 PM
What is RAID?
What is RAID? In the computer world RAID is not an insecticide. It is an acronym that stands for Redundant Array of Independent Drives. In this little blurb I will describe the most commonly used RAID versions which are RAID 0, RAID 1, RAID 1+0, and RAID 5. There are other RAID configurations, but I just don’t come across them. All instances of RAID involve the use of multiple hard drives to improve computer performance and reliability.
RAID 0
RAID 0 uses two or more drives. In a RAID 0 configuration the data is “striped” across two or more hard drives. As an example, let’s pretend you have a Word document stored on a RAID 0 disk array that consists of four hard drives. Let’s further pretend, for the sake of my little example, that your Word document is four pages long.
Then the RAID array would store one page on each hard drive. The advantage here is speed. If it normally took two seconds to load your Word document, in the example above it would take half a second.
The downside is reliability. Should one hard drive fail, then it is likely that all the data in the system would be lost. How would you reassemble your Word document from the above example if one page was missing, but you don’t know which page? Only the disk subsystem knows how the data is stored.
RAID 1
In an effort to improve reliability, RAID 1 developed. This is also called disk mirroring. In this case two hard drives are used and both hard drives have exactly the same information. Should one hard drive fail, all the information still resides on the other drive?
RAID 1 configurations are faster than a single hard drive when reading data. Since data is stored on both drives, both drives will feed the user, when data is requested. When data is saved, however, both hard drives must be updated and performance suffers.
RAID 1+0
This is a combination of RAID 1 and RAID 0. In this case you have two RAID 0 arrays and they mirror each other. Let’s take my RAID 0 example from above. If this was converted to a RAID 1+0, then I would have two four-drive arrays or eight hard drives. This gives you excellent performance as well as security in that the data is being duplicated on to drive arrays. It is, however, rather expensive. You have a lot of hard drives to buy.
RAID 5
In this situation you use a minimum of three hard drives and you can have as many as you want, after that. In a three-disk arrangement, RAID 5 uses data striping on two of the disks and the third uses some kind of data integrity algorithm to ensure data integrity.
To be frank with you, I don’t understand all the gory details of how it works; only that it does. In the RAID 5 configuration you always lose the storage capacity to one hard drive. So if I have three 50GB hard drives in a RAID 5 array, I can only store 100GB of data. RAID 5 arrays can grow to as many drives as you want. The more hard drives in your array the better your performance as your stripping your data across more hard drives.
There is a point of diminishing returns for data striping. If I go from one hard drive to two hard drives, I have nearly doubled my speed. To double again I have to go to four hard drives. The next double takes me to eight hard drives. I think you can see from this example, that you reach a point in which it is uneconomical to add more drives.
Most installations I encounter use either RAID 1 or RAID 5 or some combination thereof.
Posted by Ted at 09:32 AM
April 14, 2005
6.0 to 8.0 upgrade
I just completed a client upgrade to Microsoft Great Plains 8.0. This particular client had been on 6.0 on Pervasive on a Novell network. This means they had to replace all their hardware as well as upgrade their software.
Normally I like to set up a remote access and do upgrades like this over a weekend. Much of the upgrade is to start a process running and then wait. If I run this remotely I can just log off and then come back later to check on it progress. Sadly the only internet service they had was dial-up. They are supposedly getting DSL soon.
The upgrade was process was to first get their version 6.0 on Pervasive running on the new Windows 2000 server. Then I upgraded them to 7.5 on Pervasive. Then I migrated them from Pervasive to SQL Server. The last was to upgrade from 7.5 to 8.0. Version 8.0 only runs on Microsoft SQL Server.
The upgrade went smoothly, as I pretty much expected. This client’s operation is pretty simple as they only run Receivables and Payables. They still type purchase orders and customer invoices by hand.
I sat with the payables person to make sure vendor checks printed correctly. I like to say, half jokingly, “As a vendor, payables are the first module I like to set up.”
There was some trepidation in the staff, but after they saw how easy it was, they settled in nicely.
I feel a little frustrated in my meager selling skills. Perhaps if I was a better salesperson and not such a geek, I could persuade them to acquire and use more of the Microsoft Great Plains modules.
When a client uses Great Plains to print invoices, it keeps very detailed sales history. That makes it possible to do very detailed analysis of what customers are buying and which customers are doing the buying. I really feel helps people to better manage their business.
But, so far, I have been unsuccessful in making that case.
Posted by Ted at 05:13 PM
April 13, 2005
Microsoft releases Data Protection Manager (DPM)
Information Week has an article about Microsoft's new Data Protection Manager. It backs up to disk instead of tape. It gives you near continue backup of your files.
This release (beta) only backs up Windows file servers. Future releases will back up SQL Server and Exchange.
I’m very interested to see how the SQL one will work.
I recently put up a new server. I agonized for quite a while as to how I would back it up. I settled for an external USB hard driver. My backup needs are rather modest, but I’m still backing up about 20GB of data. The 200 GB USB hard drive holds several days’ worth of backups. I only back up important data. My feeling is I’ll be re-installing the Operating System anyway.
By backing up to the hard drive, I can quickly restore any file.
Posted by Ted at 05:33 PM
How much RAM is enough?
As I get more and more Microsoft Great Plains installations running on Microsoft SQL Server, I’m starting to make some conclusions about how much server a client needs.
SQL Server is hungry for resources. It is always best to have a server dedicated to just SQL Server. I feel that server should have at least 2GB of RAM. If you are also running Microsoft Exchange on the same server, then you should probably have 4GB of RAM.
The Microsoft Small Business Server comes with SQL and Exchange for a very reasonable price. But I feel you should populate it with a healthy amount of RAM.
Posted by Ted at 03:23 PM
April 10, 2005
Correcting the Historical Aged Trial Balance
Great Plains comes with a Historical Aged Trial Balance for both Accounts Receivable and Accounts Payable. I call these two reports HATBs. They tend to be very accurate and allow the user to compare there accounts receivable or accounts payable schedule with any date in the past. This is particularly useful when your accountant wants an aged trial balance for the prior year-end.
The exception to their utility is when the installation was not a “virgin” installation, but was an upgrade from the old DOS version of Great Plains. The old DOS version did not enforce all relational database concepts as well as Great Plains on SQL Server does. This less than perfect data gets directly converted into Great Plains.
I have a client that migrated from the old DOS version about this time last year. They are now starting to need the HATBs a lot. The one for payables, surprisingly, works fine. The one for receivables was about $100,000 off.
My method to fix them is to print a detail report from both the normal aged trial balance and the HATB for the current date. Then I compare them line for line and look for the differences.
In this case, I found only two customers with problem documents. In one case, the document went back to 1997. I figured who needs stuff that old and deleted it.
In the other case, I found two cases in which an invoice and a check both had the same document number. That means I had two checks with the same document numbers as two invoices. This had greatly confused Great Plains and they were cross applied to each other back and forth - twice.
In this situation, since I’m working in the SQL Query Analyzer, I take my time. A mistake means a whole restore from backup. Since I was using pcAnywhere over the internet and the client only has about a 128KB internet service, I had to be doubly careful. When I have this slow of a connection, it is very easy to get ahead of the system and wind up making some moves you’d really rather not make.
There were two tables that were affected, the history table and the apply table. I renamed the payments to different document numbers in the history table and then changed names in the apply table. Then I deleted the cross apply records in the apply table. I ran Check Links to reset any keys that needed tweaking. Then I re-ran the HATB for the current date.
It matched the normal aged trial balance to the exact penny! I also ran the report for 3/31/05, 2/28/05, 1/31/05, and 12/31/04 and it matched the General Ledger totals to the penny!
I sent the client an email, telling her of the results, which she should open Monday morning. This should make her job a lot easier.
This is a time-consuming tedious process, as I want to get it right the first time. However, once it’s done, I don’t have to repeat it.
Posted by Ted at 09:32 PM
April 05, 2005
How's your thumb?
It seems Microsoft researchers have come up with a user-interface that allows you to user your thumb to do things. This new user-interface is for use on Pocket PCs and such. It’s good for screens that are from two to five inches in size.
It will be interesting to see if that becomes available. One of my complaints about my Palm is it’s a little cumbersome to use. Perhaps this will be a better method.
Posted by Ted at 05:52 PM
Another Great Plains Version 8.0 Upgrade
I completed a Microsoft Great Plains upgrade from version 7.5 to 8.0 last week. Since they were already on SQL Server, the upgrade went pretty smoothly.
They have a multi-user Crystal Reports and I upgraded that to version 10. Sadly, we don’t have version 11 yet.
The only problem was the Blank PO form. There is a bug in the Blank PO form. The ship-to address does not print. But that is easily fixed. I also modified it to match what they had been printing previously.
Since I have a pcAnywhere connection to their server, and I had previously copied the Microsoft Great Plains Version 8.0 CD to their server. I was able to run the upgrade from home overnight. Then I showed up early the next morning to complete the process.
With Microsoft Great Plains, I need to do a virgin install on one station. I set that station to all the defaults I need and then make an installation template from that station.
Then it’s just a matter of going to the other stations, uninstalling the old version and installing the new version from the template on the server. It runs very smoothly and saves time. It also picks up any third party applications that have been installed.
Then I spent some time showing them some of the new bells and whistles in the new version.
In a brief conversation with them this morning I asked them how they felt about it.
They like it.
Posted by Ted at 01:42 PM
BlackBerry Beware
I see that Microsoft is putting the finishing touches on code that will allow Pocket PCs to be like a BlackBerry. The operating system is for mobile devises and is called Magneto. From what I read, they expect to have devices on the shelves by Christmas time.
It looks like this new device will route your email through your Exchange server. That should allow you to filter out a lot of the spam. It will also give you Outlook on your Pocket PC.
Posted by Ted at 10:51 AM
April 01, 2005
Getting upgraded Payroll to run
Last night I received a call from a client which I had recently upgraded to Microsoft Great Plains version 8.0. This was the upgrade that went from 5.5 on Pervasive to 8.0 on SQL.
It had gone more smoothly than I had expected. But then I always maintain the attitude, “Expect the worst, hope for the best.”
One of the modules they use the Payroll. I was able test most modules, but until they did a paycheck run, I could not be sure the upgrade was 100% successful.
When one does payroll in Microsoft Great Plains there are several steps to the process. They are...
- Enter employee hours
- “Build” the check file
- “Calculate” checks
- Print Checks
- Post Checks
The client called saying she could not Calculate checks. Since I was still at another client site, I said I would check it out, when I got home. She had email me, but had turned on my autoresponder that said I was out of the office, so she called my cell phone.
When I got home I logged into their system using my GoToMyPc connection and duplicated her process. When I tried to calculate checks, I received the error message, “The tax filing status record for tax code FED for status SIN cannot be read. Paychecks cannot be calculated.”
I used the SQL Query analyzer to look at the payroll tax tables. I had used the automatic update for them that comes directly from Microsoft Business Solutions over the net. As far as I could tell, they looked good.
Since I had previously done complete file maintenance, I did duplicate that effort.
I went online to Microsoft Business Solutions tech support Knowledge base. It’s always a challenge to figure out which parts of the error message to search for. But eventually I found one that referenced this error message: “Tax filing status record for tax code MO for status cannot be read. Paychecks cannot be calculated”
Now this was not the exact message I was getting, but it was very similar. The answer to this message was the user had a blank State Tax field.
I found the table that held the employee Federal tax information and looked at it using the SQL Query Analyzer.
I noticed when I looked at the Federal tax flag for all employees, it was MAR, SIN, or SINGLE. When I looked at the Payroll Tax tables, I could only find MAR or SINGLE tax flags.
I thought to myself, “Hmmmm. I wonder if the SIN is left over from the 5.5 and did not convert correctly.”
I went back into Microsoft Great Plains and pulled up one of the employees that showed a tax flag of SIN. When I did, I observed that there was no Federal tax filing status, married or single.
I changed it to Single and then looked at the same data in my SQL Query analyzer. What had previously been a SIN flag was now a SINGLE flag.
I was tempted to do a SQL script to reset all the flags that were SIN to SINGLE as that would have been very quick. But if I was mistaken in my theory, there would have been no way to restore back to the previous state.
I wrote a little macro to speed the process, but I changed all employees, one by one, that had a blank tax filing status to single.
I check the table again in the SQL Query Analyzer and all my SIN flags were gone. I tried to do the calculate payroll checks, and it ran like it had eyes.
I logged off the customer server, logged onto my office station and replied to the client’s email that the situation was resolved.
The best I can think is, the data in 5.5 must have been stored as SIN. But somehow, during the migration over two versions and two databases, that flag never got correctly updated.
But it’s good to go now.
Posted by Ted at 02:52 PM
Citrix - Resolved?
I have a client that is using Citrix to allow remote users to access Microsoft Great Plains. The users are in Connecticut and the server is in the Philadelphia area.
Microsoft recommends using either Citrix or Windows Terminal Server for this situation. The client has chosen Citrix.
Although it has worked well, they have experienced one user being unable to consistently log into Great Plains. She would get a message about there not being a user/password combination that she was using.
For a while, I and the MIS people at client, thought this was a user problem. But upon further analysis it appeared to be endemic to the installation.
Part of the problem was, it would happen randomly. That always complicates the issue. Today we worked on it hard and I think we may have resolved it.
The client has two Citrix servers. Citrix will automatically load balance. That is, it will seamlessly select the server being used the least as the user logs in. Once I found this out, I had the MIS person go through and make sure the SQL ODBC driver was correctly set up on both Citrix servers.
It turns out, one of the servers had the SQL OCBC driver incorrectly configured. We reconfigured it correctly and he was able to log in OK. One instance is not a guarantee, but since one server was incorrectly set up, Citrix will select the server being used least, and the problem was intermittent, I am cautiously optimistic, as Ronald Reagan used to say, the problem is behind us.
But I could be wrong. Time will tell.
Posted by Ted at 01:05 PM