Stephen Smith's Blog

Musings on Machine Learning…

Archive for May 2014

Evicting Users from Sage 300 ERP

with 9 comments


Generally Sage 300 ERP is used in a multi-user environment where users could be distributed across a large building or located in many different sites. Further Sage 300 ERP uses a concurrent licensing model for users, so if you have 10 Lanpaks then 10 people can login at once; however, it doesn’t matter which ten people it is.

Often companies save a bit of money by buying fewer Lanpaks than users of the product. Perhaps a clerk works the early shift of 7-3 and then when they go home a Financial Accountant runs some Financial Reports. But what happens if that clerk doesn’t sign off? What if they work at home and aren’t answering their phone? Now the Financial Accountant gets a message that all the Lanpaks are in use and can’t get their work done.

Evicting Users

To solve this problem Sage 300 ERP 2014 Product Update 2 will be introducing an Evict Users feature. Previously we provided a detailed list of everyone in the system and what they are doing which I blogged on here.  Now you can also kick them out of the system to recover the Lanpak for someone else to use.

From the Current Users screen there is now a push button to “Sign Out Selected Users”. You then get a dialog with a dire warning and are requested to enter the admin password and confirm to kick out the desired user.


Then in a minute or so, all the screens for that user will be terminated and their Lanpaks will be available for someone else to use.

Technical Details

So how is this accomplished? Basically when you evict a user, that screen will store an encrypted file in the shared data folder. Periodically any Lanpak Managers running will have a look to see if there is a new file and if there is it will see if it is for users they are managing. If so, Lanpak manager will kill the processes of all the screens they are running. The file is left in place for a few minutes, so this particular user won’t be able to sign in again immediately.

This is a fairly simple scheme that is fairly effective for recovering Lanpaks. It works both for regularly run screens from the desktop as well as web deployed screens from the Web Desktop or from Sage CRM.

Since it’s by user, you can kill the ADMIN user which will kill yourself. If all your users sign in as ADMIN then it will kill all the users on the system. So beware that if multiple users share a user id, then they will all be killed and not just one workstations.

Performing Upgrades

Another use case that this method only partially addresses is kicking everyone out of the system so you can perform an upgrade (like a Product Update). Generally a DLL or EXE file in Windows is locked if a running process uses it. Hence you can’t update Sage 300 if someone has a4wapi.dll in use for instance. It could be that this method does gets everyone out of the system, but there are a few cases which may not work:

  • If someone signs off the Sage 300 Desktop but leaves it running. In this case the EXE and DLLs are still in use, but since it isn’t using a Lanpak and isn’t associated with a user, it can’t be killed this way. However I tend to think this is fairly unlikely.
  • It won’t be effective against things that quickly open sessions, do something and then close the session. This would include things like the Sage CRM integration where the custom Sage CRM pages open a session load their data and close the session. However things like this tend to be Web Servers and can usually be stopped remotely or at least from a central place.
  • Things that we allow to use Sage 300 without using a Lanpak. This would include things like parts of the Sage CRM integration, the Sage HRMS integration and the Sage 300 Portal.
  • For third party products, if they are full SDK, it will definitely work on them. If they aren’t full SDK it may or may not work depending on how they are built.

Keep in mind that the main purpose of this feature is to manage Lanpaks, performing upgrades is just a secondary things, where hopefully it helps, but may not be a complete solution.

The Scary Warning

The warning message when you run this is fairly severe. Part of this is because we are killing the processes that are connected to our API. Generally you won’t corrupt the main database because everything is protected by transactioning. So if you do kill the process while they are say posting a batch, it just means the transaction in process will be rolled back and they will have to do it again later. Generally the expectation is that this feature is used once people go home and aren’t doing anything which would be harmless. Further in the user list screen you can see what people are doing, so don’t kill the person running Day End.

However if someone is using the UI and they are resizing columns in a grid, you could catch things at the wrong time and corrupt a *_p.ism file. But these can be deleted and sometimes repaired with ScanIsam. If you are running a non-SDK third party product, I can’t really say what will happen if it’s killed.


The Evict Users feature is the number one feature as voted on, on our Ideas web site and this is now in the product. So keep making suggestions to and voting on suggestions that are in the system that you would like to see implemented.

This features will make it easier for companies to manage their Lanpaks and get better value from the system. Hopefully this will also make managing upgrades a bit easier as well.

Written by smist08

May 24, 2014 at 4:17 pm

On Organizing Agile

with 6 comments


Generally Agile Programming is first taught as a very simple process, only involving some simple tools found in most kindergartens. The basic ideas of Agile Programming are quite simple and designed to make software development easier with less wasted work. However many people that adopt Agile find this transformed into quite a rigid bureaucratic system that isn’t very productive. What are a few things that can go wrong? How can you return to the simplicity of the original Agile goals? How can you track and manage large projects with many teams and dependencies in an Agile world?

Agile Manifesto

Agile was started by a group of programmers who came up with a simple set of guiding principles.


The purpose of this wasn’t to obliterate all the items on the right, it was to set some priorities. I think a lot of times when organizations adopt Agile, they follow this initially, but over time develop fixed ways of doing things and begin to have rationalizations that when they are doing the things on the right, they are really doing the things on the left. It takes a bit of organizational self-awareness to stay on guard against this.

Organizing Big Projects

A lot of simple courses on Agile focus on projects executed by one sprint team. Then to scale the process they wave their hands and just say you have multiple sprint teams executing off the backlog. Sounds good but tends to neglect a few factors. One is that different teams develop different expertise. Perhaps because they have a lot of experience in a given area or they have been tasked with specializing in a specific area like perhaps interaction design. Often in a large project it is very inefficient to have all the teams taking items from the same backlog. Often it’s better to have the teams specialized on separate parts of the project. People want to be masters of what they do, and trying to make everyone a jack of all trades just makes people unhappy. Further software is complex and subtle, having teams really know a specific area can be a huge help to move things ahead.

Once you start developing these specialization, you start introducing dependencies where one team will be waiting for another. Once you have dozens of teams, then you will need some sort of Project Management structure in place to track of this. A simple burn down of a backlog just doesn’t cut it.

Agile versus Waterfall

I find that the Agile versus Waterfall debate tends to indicate problems. People will say they won’t do something because it’s “Waterfall” and not “Agile”. But the truth is that the elements of Waterfall still need to be done. There has to be some program design, there has to be some architectural design, and there has to be some documentation. There is going to be integration and system testing. Just the goal is that these aren’t the main activities and they are generally done in much smaller increments than Waterfall.

When people refuse to do tasks because they are “Waterfall”, it is usually a warning sign that something important is going to be missed because someone dislikes a particular task. Generally your ears should perk up when you hear this argument being used.

Are You Really Agile?

Another problem area I see is when Agile teams become very non-agile. By this I mean they do sprint planning and then for the duration of the sprint absolutely refuse to do anything that wasn’t specified in sprint planning.

This can be good for getting the backlog reduced. But if priorities change in the backlog, it could mean they are now doing the wrong things. This usually means that discoveries and knowledge learned in a sprint isn’t used until the next sprint. Further if a customer issue comes up, it can look very bad to customers if their problem isn’t going to be even considered till next sprint planning.

Further if your product runs in the cloud, you need to be instantly responsive. In this case your teams do need to drop everything when your live system has a problem. You can’t let your cloud service be down until the next sprint.


One commonly proposed solution to the above is to use Kanban. Here you don’t do sprint planning and always execute the top priority items in the backlog. There is further discipline to help make this work like limiting work in progress. To have Kanban work once you have a production system requires really strong product owner to avoid having all capacity going to the production system. Often this means holding a hard line on what is really important for customers, fixing minor problems or introducing more important new features.

Working with Off-Shore Teams

If you are working with off-shore teams then documentation and communications become much more important. You also need to be careful not to introduce bottlenecks that would stop them getting their work done (like waiting for a remote product owner to update/input backlog stories).


Most big multi-team projects usually have at least one off-shore team these days. In order to scale product development departments being able to work effectively across multiple locations in very different time zones becomes crucial.

Often if you are having problems with your Agile development process, then adding an off-shore component will magnify them and lead to much more serious problems.

Similarly teams are often not so co-located due to team members working at home, perhaps in a different city. There are many new technologies to help this work as I blogged on here.

Backlog Priorities

Setting backlog priorities is often quite controversial because of the mixed needs of different members of the product owner community. There has to be a balance of what is needed for customer, what is needed by dependent teams as well as architectural and operational issues. It takes a strong product owner with a clear understanding of these issues to set the priorities appropriately. Further the product owner needs the power to stick to his priorities and not to be continuously overridden by people escalating issues up the chain of command.


Keeping large projects Agile is a real challenge. Keeping Agile teams Agile over the years is a major challenge. People like routine and are always trying to get a nice regular fixed routine. This can be nice, but not entirely realistic as everyone tries to do things in Internet time while handling problems in cloud services in real time.

More Thoughts on Security

leave a comment »


Last week I blogged on some security topics that were prompted by the Heartbleed security hole. Heartbleed was hot while it lasted, but in the end most servers were quickly patched and not a lot of damage was reported. Now this last week Heartbleed was completely pushed aside by the latest Internet Explorer security vulnerability. A lot of the drama of this problem was caused by speculation on whether Microsoft would fix it for Windows XP. Although the problem existed in all versions of Windows and IE, it was assumed that Microsoft would fix it fairly quickly for new versions of Windows, but leave Windows XP vulnerable.

The IE Problem

Microsoft’s Internet Explorer has had a history of problems with letting rogue web sites take over people’s computers by downloading and executing nasty code. The first cases of this was that IE would run ActiveX controls, which basically are compiled programs downloaded to your computer and then run in the Browser’s process space. These led to all sorts of malicious programs and viruses. First Microsoft tried to make ActiveX controls “signed” by a trusted company, but generally these caused so many problems that people have to be very careful which ActiveX controls to allow.


With ActiveX controls blocked, malicious software writers turned to other ways to get their code executed inside IE. A lot of these problems date back to Microsoft’s philosophy in the early 90s of having code execute anywhere. So they had facilities to execute code in word processing documents, and all sorts of other things. Many of the new malicious software finds old instances of this where Microsoft unexpectedly lets you run code in something that you wouldn’t expect to run code. Slowly but surely these instances are being plugged one by one through Windows Updates.

The next attack surface is to look for bugs in IE. If you’ve ever tried running an older version of IE under Bounds Checker, you would see all sorts of problems reported. Generally a lot of these allow attackers to exploit buffer overrun problems and various other memory bugs in IE to get their code loaded and executing.

Another attack surface is common plugins that seem to always be present in IE like for rendering PDF documents or for displaying Adobe Flash based websites or using Microsoft Silverlight. All these plugins have had many security holes that have allowed malicious code to execute.

Plugging these holes one by one via Windows update is a continuing process. However Microsoft has taken some proactive steps to make hacking IE harder. The have introduced things like more advanced memory protections and ways to randomize memory buffer usage to make it harder for hackers to exploit things. However they haven’t trimmed down the functionality that leads to such a large attack surface.


The latest exploit that was reported in the wild last week got around all Microsoft’s protections and allowed a malicious web site to take over any version IE on any version of Windows that browsed that site. Then the malicious web site could install software to steal information from the affected computer, install a keyboard logger to catch typed passwords or install e-mail spam generation software.

Why the Fuss?

This new exploit was a fairly typical IE exploit, so why did it receive so much attention? One reason is that after Heartbleed, security is on everyone’s mind. The second is that Microsoft has ended support for Windows XP and publicly stated it would not release any more security updates. So the thinking was that this was the first serious security flaw that wouldn’t be patched in Windows XP and havoc would result.

However Microsoft did patch the problem after a few days, and they did patch the problem on Windows XP as well. After all Windows XP still accounts for about a third of the computers browsing the Internet today. If all of these were harnessed for a Denial of Service attack or started to send spam, it could be quite serious.

People also question how serious it is since you have to actually browse to the malicious web site. How do you get people to do this? One way is when URLs expire, sometimes someone malicious can renew it and redirect to a bad place. Another way is to register URLs with small spelling mistakes from real websites and get unwary visitors that way. Another approach is to place ads on sites that just take the money without validating the legality of the ad or what it links to. Sending spam with the bad URLs is another common approach to lure people.

How to Protect Yourself

Here are a few points you can adopt to make your life safer online:

  • Use supported software, don’t use old unsupported software like Windows XP. Windows 7 is really good, at least upgrade to that. If your computer isn’t connected to the Internet then it doesn’t really matter.
  • Make sure Windows Update is set to automatically keep your computer up to date.
  • Don’t click on unknown attachments in e-mails
  • If you receive spam with a shortened or suspicious URL link, don’t click on it.
  • Go through the add-ons in your browser and disable anything that you don’t know you use regularly (including all those toolbars that get installed).
  • When browsing unfamiliar sites on the web, use a safer browser like Google Chrome. Nothing is foolproof but generally Chrome has a better history than most other browsers.
  • Make sure you have up to date virus scanning software running. There are several good free ones including AVG Free Edition.
  • Make sure you have Windows Firewall turned on.
  • Don’t run server program you don’t need. You probably don’t need to be running an FTP server or an e-mail server. Similarly don’t run a whole bunch of database servers you aren’t using, or stop them when not in use.
  • Don’t trust popup Windows from unfamiliar or suspicious websites. I.e. if suddenly a Window pops up telling you to update Java or something, it’s probably a fake and going to install something bad. Always go to a company’s main site of something you are going to install.
  • Never give personally identifiable data to unknown websites, they have no good reason to know your birthday, phone number or mother’s maiden name.
  • Don’t use the same password on all websites. For websites that you care about have a good unique password.
  • Be distrustful of URLs that are sort of right, but not quite (often it’s better to go through Google than to spell a URL directly). Often scammers setup URLs with common spelling errors of popular sites to get unsuspecting victims.


There are a lot of bad things out on the Internet. But with some simple precautions and some common sense you can avoid the pitfalls and have an enjoyable web browsing experience.


Written by smist08

May 3, 2014 at 4:25 pm