ABECAS Insight

This is Part 3 of the TaskAgent & PowerShell series. Here you can find Part 1 and Part 2 posts. Check the Downloads section at the end of the post for the available source files and PDF version of the full post.

Scenario 3 – Web Dashboard powered by TaskAgent and Windows PowerShell

The third task which I wanted to automate involves the periodic update of an online dashboard which displays a summary of different types of business data – . This time I will use some T-SQL scripting from within the PowerShell script to pull the necessary data from the database. In addition, to make the script usable across different databases, I will be passing the database connection information into it via command-line parameters.  Here’s how this is done:

1.       We will start by creating the “frame” for our online dashboard. I will use a simple HTML file - dashboard.html  -which has just a heading text and a table with two rows and two columns – this will give us the four cells where the dashboard data will be presented. Each dashboard cell will be a separate web page represented by an IFRAME element. Here is the content of the dashboard.html file:

In addition to the dashboard HTML file, create four files for the different frames – frame1.html, frame2.html, frame3.html and frame4.html – the files can be simply blank or contain some default text to be displayed while there is no summary data. These files will later be automatically replaced by the TaskAgent with ones containing our live data. Here is how the directory containing the dashboard HTML files should look:

Here is how the empty dashboard should look while there is no data to display:

2.       Create the PowerShell scripts which will do all the processing.  We will use a separate script to update each dashboard cell. This will provide the flexibility of updating the different parts of the dashboard at different intervals (using different TaskAgent jobs) or using data from different data sources. The demo will use a single job to process all four tasks, but it is very easy to separate the tasks into different jobs with different schedules. You can use the ready files available from the download section – demo_webdashboard_frame1.ps1, demo_webdashboard_frame2.ps1, demo_webdashboard_frame3.ps1, demo_webdashboard_frame4.ps1

I will briefly explain what the purpose is of the different sections of the first script file. The scripts for the other frames are similar – only the SQL query and the frame HTML file which they update are different.

The first section of the script handles the input parameters. The scripts expects two parameters – the SQL server name (specified by /S:<server_name>)  and the database name (specified by /D:<database_name>). It checks if the required parameters are provided and extracts their values. If any of the required parameters is not provided, the script throws an exception with the appropriate message.

The second part of the script prepares a SQL command object and a SQL connection object and executes a SQL query to get the summary data. The section marked with blue is the SQL query which is different in each of the frame scripts. The database connection is created using the information specified by the command-line parameters. It uses integrated security (Windows authentication) instead of requiring username and password.

The last part of the script formats the retrieved SQL data in an HTML table and writes the results to an HTML file. The section marked with blue is the HTML file name which is different for each of the frame scripts.

3.       In the TaskAgent console, create a job with a time schedule (similar to the way it is done for the prior two scenarios)

4.       Create a task for the job created above and select “Run External Program” as the task type.

5.       On the “Task Settings” – “General” tab, in the “Program or File to Run” field, enter the PowerShell executable “powershell.exe” and in the “Command-line Parameters” field, enter the full path to the PowerShell script file. The difference here is that in addition to the script file, we provide as part of the command-line parameters the database connection information which should be used by the PowerShell script. In this particular case, we are providing only the SQL server name and the database – the PowerShell will use Windows authentication to connect to the database. This requires that the Windows credentials which will be used to execute the task have a corresponding SQL login on the specified SQL server. I chose to go this route to avoid entering in plain text the SQL server username and password. I recommend that you use this approach as well because it does not expose any secure information.

Note that the script input parameters are surrounded by single-quotes.

6.       On the “Security” tab provide the necessary Windows account credentials (which also have a corresponding SQL login account) if the TaskAgent service account does not provide them.

7.       On the “Execution Result” tab configure what the TaskAgent should do after the external program has been started.

8.       Repeat the steps 4 through 7 three more times – the only difference each time will be the PowerShell script file which you specify in the Command-line parameters field. The end result should be a job with four tasks – each task executing one of the four PowerShell scripts which we created in Step 2.

Do not forget to configure the job task workflow –  use the “Workflow” tab to specify how the tasks should be executed. The end result should be similar to this:

Save the job and give it a test run. Depending on your TaskAgent configuration it may take a minute or two to complete the execution of all four tasks. At the end, the updated web dashboard will look similar to this.

Depending on the job schedule, the TaskAgent will periodically update the dashboard with the latest information from your database. You can even configure the different tasks to pull information from different databases – this way the dashboard will be presenting on a single page summary information from multiple data sources. By modifying the SQL queries you can present different summaries. You can even add new “cells” to the dashboard to expand the presented information. The current style of the dashboard is not perfect and requires the attention of a web designer but I hope that at least its business value is clear.

Downloads

PDF version of the full post is available here: TaskAgent & Windows PowerShell

The demo source files are available for download here: Sample PowerShell scripts and other source files from the demos

This is the second part of a series of posts related to the TaskAgent and Windows PowerShell. You can find the first part here: TaskAgent & Windows PowerShell - Part 1

Check the Downloads section at the end of this post for a PDF version of the full post and related source files.

Scenario 2 – Check the available disk space and send an e-mail notification

This scenario attempts to automate a standard system administrative task by periodically checking the available disk space on multiple servers and sending e-mail notifications if the free disk space is below a certain limit. To accomplish this I will use again a Windows PowerShell script which will collect the necessary information using Windows Management Instrumentation (WMI) objects and send the notifications using .NET objects. Lets start:

1.       We will start by creating the PowerShell script. For your convenience, you can download the source for this demo and use the file demo_checkdiskspace.ps1

I will briefly explain what each part of the script is doing:

In the first section we just declare the list of computer names which should be checked and an empty array variable to store the results. Remember to change the list of server names to something which applies to your network.

In the second section the script iterates through the list of server names and uses the WMI object Win32_LogicalDisk to collect the disk drives information (marked with red).  Since the servers may have multiple drives,  the script iterates through the disk drives information of each server and adds to the result information the server name, calculates the percent free disk space and uses the calculated percentage to place the server disk drive one of the following 3 groups: less than 20% - CRITICAL, less than 35% - WARNING and everything else – OK (marked with blue). You can change these percentages to different levels if necessary.

The third part of the script further filters the results collected so far and leaves only the ones with CRITICAL or WARNING status. You can omit this step if you would like to send in the e-mail a report which includes information for all disk drives, not only the ones which are running low in free disk space.

The last section of the script checks if there are any results and formats them in a nice report which is written to a text file (marked with red). The script then uses a .NET object to prepare an e-mail message and send the results in the body of the message (marked with blue). Remember to change the From and To e-mail addresses. If your SMTP server requires authentication, you can also specify the necessary username and password.

2.       Create a TaskAgent job and add a time event for it. (see Scenario 1 for more details how to do this)

3.       Add a task for the job which we created above. The task type should be “Run External Program”.

4.       On the “Task Settings” – “General” tab, in the “Program or File to Run” field, enter the PowerShell executable “powershell.exe” and in the “Command-line Parameters” field, enter the full path to the PowerShell script file.

5.       On the “Task Settings” - “Security” tab, you can provide the Windows credentials which the TaskAgent should use when executing the external program (in our case this is the powershell.exe). By default, the TaskAgent will use the same credentials as the ones which the TaskAgent service is using. Our PowerShell script is using WMI to interrogate multiple servers for their disk drives – this requires administrative permissions which the TaskAgent service account may not have. If this is the case, on the “Security” tab enter the credential for a Windows account which has the necessary permissions.

6.       On the “Task Settings” – “Execution Result” tab, you can specify what the TaskAgent should do after the external program is successfully started. In this specific case, I have configured the task to wait for 20000 milliseconds (20 seconds) for powershell.exe to finish its execution. If the powershell.exe does not finish within the allocated period, the TaskAgent will terminate the external process. In addition, the TaskAgent can examine the exit code of the external process to determine whether the execution was successful or not. In this specific case, I have configured the task to accept only 0 as a successful exit code.

Save the job and test it. If everything is correct and some of the servers in your list are running low on free disk space, you should get a report containing information similar to this:

Not bad for a short script – by integrating the TaskAgent with PowerShell, WMI and .NET we can automate a multitude of administrative and business tasks.

Downloads

You can download a PDF version of the full post here: TaskAgent & Windows PowerShell

The related source files are available for download here: Sample PowerShell scripts and other source files from the demos

­During the Argos Software users’ conference in October 2008, I presented a session on how to extend the standard TaskAgent functionality using scripting with T-SQL and Windows PowerShell. In several blog posts I will try to make the examples and materials from that session available for all Argos customers. Check the “Downloads” section at the end of this post for the demo source files and other available downloads.

Prerequisites

You will need to install the latest version of the TaskAgent (available for download on our FTP server here: ftp://ftp.abecas.com) and Windows PowerShel version 1.0 (available for download here: http://www.microsoft.com/downloads/details.aspx?familyid=6CCB7E0D-8F1D-4B97-A397-47BCC8BA3806) in order to be able to use the examples below.

Scenario 1:  Automate file and directory maintenance

One common task which I have to do quite often involves maintenance of different files and directories. I wanted to configure a simple TaskAgent job which will monitor a specific file system directory every 15 minutes and will delete files which match certain criteria – in this specific case, delete all files which have been created more than 8 hours ago. Setting up in the TaskAgent a job schedule which triggers the job execution every 15 minutes is very easy. However, configuring a task to delete the necessary files is not straight forward. Initially I tried to do this with a simple batch file, but getting the current system date and time and using it to filter files proved to be quite difficult. After some research I found an easy answer which was using the newest scripting offering from Microsoft – Windows PowerShell, which is a standard part of Windows Server 2008 and is also available for Windows XP and Windows Server 2003. With PowerShell, all I needed to write is a single line of script code to achieve my task goal:

dir “D:\Temp” | ? {$_.CreationTime -lt (get-date).AddHours(-8)} | del –recur

This single line of code performs the following:

1.       Retrieves the list of all files and sub-direcotries in D:\Temp

2.       Iterates through the list and checks if the creation date & time of the file/sub-directory is more than 8 hours ago

3.       Each file/sub-directory, which matches the criteria above, is deleted and in the case of directories, all sub-directories and their content is deleted as well.

It is beyond the scope of this blog post to provide a full explanation and reference for using the Windows PowerShell – you can refer to the multitude of available online resources for that (one such reference can be found here: http://channel9.msdn.com/Wiki/WindowsPowerShellWiki/). However, I do want to show you how to integrate the PowerShell scripts in the TaskAgent to extend its functionality and automate a wide variety of tasks.

Here is what we need to do for our single-line script above:

1.       If you have not installed the Windows PowerShell on the TaskAgent server, do so.

2.       Open the PowerShell command prompt, enter the following command:

Set-ExecutionPolicy RemoteSigned

and press “Enter”.

This command will enable the execution of PowerShell script files which are created on the TaskAgent server, because by default this option is disabled to prevent the execution of malicious scripts. (note: Windows PowerShell provides also options to enable only the execution of digitally signed scripts – you will need to have a certificate which can be used to sign your scripts). If you enter the command

Get-Help Set-ExecutionPolicy

You will get detailed description for the available options.

3.       Create a simple text file using Notepad, copy and paste the script line above into your text file and save the file in a directory accessible by the TaskAgent using as filename demo_deletefiles_bycreationdatetime.ps1.

Note the extension .ps1 – by default, this is the extension used for PowerShell script files. If you are using Notepad to create the script files, when saving the files make sure that you specify in the “Save As Type” the option “All Files” – otherwise Notepad will append the default .TXT extension to your filename.

You can use any text editor to create or modify the script files. The only requirement is to save the files as plain text ASCII or Unicode files. My favorite text editor is UltraEdit – it provides among other things color syntax highlighting for the PowerShell scripts which makes it easier to edit them. In the screenshot below, there is an extra line which starts with # - this designates a comment in your PowerShell script file. Such lines will be ignored during the script execution, they are used only to document your script code – very useful for the future script maintenance.

4.       Open the TaskAgent console and make sure the RunProgramWorker is registered and enabled – this is the worker which will be used to process the script tasks

5.       In the TaskAgent console, create a new job and add a date & time schedule for it – for this example I used a time schedule which is triggered every 15 minutes, every work day from 8am to 5pm – feel free to set the time schedule as you see fit. (note: to test the script task you do not even need a schedule – just a job with the necessary task, the job can be triggered manually using the option “Run Job Now”)

6.       Add a task for the job created above – for the task type, select “Run External Program”

7.       On the “Task Settings” – “General” tab, in the “Program or File to Run” field, enter the PowerShell executable “powershell.exe” and in the “Command-line Parameters” field, enter the full path to the PowerShell script file.

As a rule, I always surround the file paths with double-quotes to avoid errors if the file path contains spaces.

8.       On the “Task Settings” - “Security” tab, you can provide the Windows credentials which the TaskAgent should use when executing the external program (in our case this is the powershell.exe). By default, the TaskAgent will use the same credentials as the ones which the TaskAgent service is using.

9.       On the “Task Settings” – “Execution Result” tab, you can specify what the TaskAgent should do after the external program is successfully started. In this specific case, I have configured the task to wait for 20000 milliseconds (20 seconds) for powershell.exe to finish its execution. If the powershell.exe does not finish within the allocated period, the TaskAgent will terminate the external process. In addition, the TaskAgent can examine the exit code of the external process to determine whether the execution was successful or not. In this specific case, I have configured the task to accept only 0 as a successful exit code.

This is all – now save the job and we are ready to test it! You can manually trigger the job by right-clicking on it in the TaskAgent console – Jobs list and selecting the option “Run Job Now”.

Online Resources

Below is the list of some of the available online resources which I have used.

•        Windows PowerShell

http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx

http://www.microsoft.com/technet/scriptcenter/topics/winpsh/manual/start.mspx

http://channel9.msdn.com/wiki/windowspowershellquickstart/

•        Batch Files

http://commandwindows.com (Great One!)

•        SQL Scripts

http://msdn.microsoft.com/en-us/library/bb510741.aspx

The example above is a simple one. In the following posts I will  show more elaborate PowerShell scripts.

Downloads

A PDF version of the contents in this blog post is available for download here: TaskAgent & Windows PowerShell

A ZIP file containing the demo source files is available for download here: Sample PowerShell scripts and other source files from the demos

If a Task Agent job appears to be “stuck” in a processing state and cannot be disabled or modified, perform the following steps to forcefully reset the running state of the Task Agent job.

Important Note: Some Task Agent jobs may require longer period of time to complete their processing. Proceed with the following steps only after the Task Agent was not able to completed the job (with either success or failure result) within a reasonable amount of time.

Step 1. Stop the Task Agent service on the local machine and any other machine where the Task Agent service is installed. You can view the list of running Task Agent worker processes by selecting the “Task Queues” node on the Task Agent Console menu tree.

Important Note: Failure to stop all Task Agent services while performing the following steps may result in Task Agent jobs or tasks to be left in an unstable state.

The column “Machine Name” of the Task Workers Summary section contains the machine names where a Task Agent service is running. Use the Refresh button to get the current list of Task Agent worker processes.

Step 2. In the Task Agent Jobs list, select the job which is in a running state and click the “View Job History” toolbar button (or right-click the job and select the option “View Job History” from the context menu)

Jobs which are in a processing state display as their “Last Run On” information the text “running now”. Use the “View Job History” option to display the job processing history dialog for the selected Task Agent job.

Step 3. The job history dialog will be displayed. In the list of job processing records, locate the record(s) which are not completed and whose Processing Result is “In Progress”. Once you have located the record(s) select them and press the Delete key on the keyboard (or right-click on the selection and choose “Delete Selected” from the context menu). You will be prompted to confirm the deletion of the selected record(s).

Important Note: If any log information is available for the processing record(s) which are about to be deleted, you can copy the text from the log messages and save it in a text file for future troubleshooting reference.

You can sort the list by clicking on the column headers to display the records which you are looking for at the top of the list. If none of the displayed records is still in progress, you can try showing more records by using a bigger result set for the option “Show the last…job processing records” and clicking the Refresh button.

Step 4. Since the job processing record indicates that the job is still in progress, a warning message will be displayed.

Important Note: Make sure that the deletion of the job processing records is performed while all Task Agent services (running on any machine) are stopped.

Step 5. Once the job processing record(s) are deleted, close the job processing history dialog and refresh the Task Agent Jobs list. The job will be reset and will no longer be in a “running” state. You will be able to disable or modify its configuration as needed.

Important Note: Be sure to start the Task Agent service(s) which have been stopped in Step 1 after the Task Agent job issue has been resolved.

A PDF file containing the information from this post can be downloaded using the link below:

Task Agent Job Troubleshooting

For those of you who customize reports in Abecas Insight using the Report Builder interface, I have a couple of suggestions you may wish to use during the customization process.

First, I highly recommend that you do your customization in the Practice database. It is helpful to have a Practice database with current data, so you may wish to restore the Practice database from a recent backup of your live database, which will provide plenty of familiar, real world data for you to run your reports against.

Second, if you haven’t already done so, or have not done so recently, I suggest you visit the Argos Software Support Web Page to review the available topics relating to working in Report Builder.

The Support Web address is: http://support.abecas.com

After logging in to the site, click the Downloads link near the top of the page. There you will find a number of Webinars and How To files on various topics. There are currently four Webinars relating to Report Builder in Abecas Insight and fourteen ‘How To” documents.

In order to create a custom report, you will need to begin with one of the Standard Abecas formats for the type of report you want to create. Go to the report type that you want (Bill of Lading, for example) and select a Standard Format that approximates the report you want to create. Check to make sure that it contains the primary data fileds that you want and that the report can run against the level of data that you desire (Lot, Sublot, Serial Number, etc.). Select a limited range of data in the Range Selection dialog and run a Print Preview to compare the available formats. Even if there is only one Standard Format, you should run a preview against a limited selection of data as this data will display in your design preview as you work in Report Builder and a limited set of data (one or two pages) will enable each preview page to load quicker.

Bill of Lading Record Range Selector

Once you have decided upon the Standard format which you will use as your basis for your custom report, click the Customize button in the top line menu of the Record Range dialog and click the ‘Create New Report Format’ option. This will create a copy of the standard format you selected. You should give this report a name which will be meaningful to you and your users, e.g., ‘Bill of Lading for ABC Account’ and type the name of the original standard report format in the comments area of the naming dialog, along with any other comments you deem important. When you click OK, the Report Builder interface will launch and you can begin your customization.

Naming New Report

As you make changes, it is a good practice to save your changes regularly by clicking File, then Save. It is also a good idea to save you reports to a file folder where you can access them when you want to move them to your live database. On the support web page there are two ‘how to’ articles that will tell you how to Save an RTM and how to Import an RTM (the saved report template).

Doing your development in the Practice database will ensure that you do not effect the integrity of any data in the live database, so if you changes the stage of a transaction or generate an invoice or create additional test data, you will not negatively impact on-going operations. Also, your users will not be able to run your new format until you have completed it, tested it and loaded it into the live database.

The ability to save and import custom reports also gives you an opportunity to work with other users and exchange formats that you have developed should you choose. With other users, you can work cooperatively to develop custom reports and share your knowledge and results to the benefit of both users.

As you know, we maintain two versions of our software. Our ‘release version’ is stable and subject only to maintenance programming, not database modification or adding enhancements. Our programmers apply their main efforts to our ‘development version’. This version is where we enhance the software, add new features and perform custom programming. Our goal is for the development version to become our release version after 3 months. Insight releases will now occur at the start of each quarter.

Earlier this month, our 7.3 development version became our release version, with the new 7.4 created as our development version. Significant enhancements have been added to the release version 7.3 and we encourage you to update, as convenient. The release notes available under the Help option list the major changes in this version. We will also highlight some of these enhancements in our first newsletter.

In the past we were forced to work on release versions to an extent that was not desirable. The needs of some customers who were unable to upgrade to obtain required enhancements drove us to undertake enhancements in both the release and development versions simultaneously. This parallel development created an unmanageable demand on QA to prove capability in both systems. This experience has led us to implement a hard rule – all development will be restricted to the current development version only. The result of this for the vast majority of our users will be increased stability of the product and an enhanced user experience.

In recent months, Argos Software has comprehensively reviewed the service and support we deliver. This review included an extensive customer satisfaction survey to help us better understand your needs and how we can meet them. We are grateful to everyone who took the time to contribute comments and suggestions. Your detailed and thoughtful feedback is invaluable today and in planning for the future.

We recognize that installing our software is only the start of a long and close relationship between our companies. This relationship is the focus of our business and we are delighted that so many of you feel that the product meets your needs and that our staff is friendly, helpful and knowledgeable. Several customers reminded us of their strong loyalty to Argos Software and almost all indicated willingness to be a reference for potential future customers. We appreciate your support and are working to ensure that we earn that support every day.

As well as positive feedback, some of you shared concerns related to our product, support or company. In some cases, these concerns required immediate action on our part. We appreciate this feedback and are committed to correcting our shortfalls where they already exist, and making systemic changes to ensure long term improvement.

Service and support are critical issues for all of us. Day-to-day performance of the software is important and our reaction when something goes wrong or needs to be changed is a key element of customer satisfaction.

We acknowledge your candor and generosity in providing us with your frank appraisal of our successes, as well as our shortcomings, in admin/billing, communication, account management/sales, and support. This feedback has helped us to address the issues and we are progressively making improvements in each of these areas.

Many of you expressed a desire for improved communication about updates, new features, the direction of our company, Webinars and other resources as well as more direct involvement with Argos and other users. In response, we will introduce a quarterly newsletter starting next month, including tips and tricks, an improved website, and email advice about relevant updates and new products.

We are currently researching how best to implement your desire to communicate with other users through an online bulletin board or blog. This online forum was launched at the September Users Meeting to facilitate a community of best practice, allow knowledge sharing between customers and provide a valuable opportunity for us to learn more about how you use our software, and your additional needs. We will progressively review and improve the structure of the online forum based on your feedback.

In response to your comments, we are modifying the make-up of our account management/sales team to carefully match you with the most appropriate specialized account manager. Some of you have been, or soon will be, assigned to a new account manager dedicated to helping you get the most out of the software and your relationship with us.

Our Support team is our direct interface between your business and ours. It is also an area that received considerable comment and constructive criticism. We have implemented a number of changes to improve response times and support service. These changes are spearheaded by our Support Manager, Harvey Clement, who brings with him extensive experience in quality assurance, as well as excellent product and industry knowledge. We are also making changes in the way service requests are managed to ensure that you receive prompt solutions and ready access to the specialized staff who can best address your concerns.

Our webinars are positively regarded by those who have participated or accessed them from our web site. We will be working to improve the quality and variety of these valuable training tools and to better promote awareness of this resource. All of our webinars are catalogued and available on our support web site. This site may be accessed from our ‘Help’ option and webinars are available under ‘downloads’. If you do not have a log-in for our support site, please call our Support Team.

Some of you had specific suggestions about ways we could enhance our software to better meet your needs. These suggestions have been recorded for the support and programming teams. Some of the suggestions have already been implemented and others will be introduced over time. We are particularly focused on suggestions that would be beneficial to a large share of our users. Suggestions that are specific to a single user or a small group will continue to be handled as custom programming requests.

Again, thank you for your time, input and suggestions. If you have additional comments or suggestions you would like to make, please call Heather at 888-253-5353 or email her at heatherh@argosoftware.com

Customers from the Enterprise, Warehouse and Freight Management business areas attended the highly successful Argos Software Fall 2007 Users’ Conference. Workshop sessions were constructed around the theme of Business Process Management and explored ways that ABECAS Insight can enhance your business operations, now and in the future.

Company President Alan Thodey talked about the future of Argos Software and the ways that the product and the company are adapting to a changing environment. A recent survey of customers resulted in several new strategies to increase communication with customers, and between customers with similar interests.

A blog where Argos Software can post news, how-to documents, tips and tricks and other articles of interest has been published and will be regularly updated. You can find these articles at http://blog.abecasinsight.com.

A forum where users can post suggestions, comments, work-arounds and questions as well as sharing their success stories has also been established. The forum can be found at http://forums.abecasinsight.com and all users are encouraged to contribute to this resource to learn and share their knowledge about the system and to be part of an active community of Argos Software expertise.

Interactive sessions focused on exploring requirements for a future version of the software that is currently in development under the working title of “Version 9.” Changes to hardware and the Windows operating system demand some changes to the software as it is today and the new product will take advantage of additional capabilities in the Windows environment and SQL database management to deliver superior business results. Participants contributed their ideas about how they would like the new software to look and function.

Several participants found these interactive sessions particularly valuable. One attendee wrote on a feedback form: “I really enjoy and learn more from the interactive sessions.” As Argos Software staff gathered information about customer requirements for the new product, customers learned more about the future of the system. “V9 looks very promising,” one customer said.

Several workshop sessions focused on new functionality available in version 7.3, the current release version of ABECAS Insight. Training sessions on using the Task Agent to automate routine activities were popular with participants. Several attendees reported being eager to try out the Task Agent to lighten the load on users. This robust new feature has considerable potential to improve efficiency in the administration of your business.

Feedback from participants in the conference was positive and encouraging. One customer described feeling confident about the software’s ability to “handle our business needs now and in future.” Another user summed up by saying: “I like the direction I see the company going.”

Argos Software staff and customers who attended the Fall 2007 Users’ Conference mingled informally at a social outing on the Sunday before the conference. Participants had the opportunity to take part in either a friendly golf day with Argos staffers, Rex Von Nothdurft and John McPherson, or a tour of Yosemite National Park with Programming Director, Dave Yost.

The Argos Software Yosemite bus tour stopped for photo opportunities and walks at several of the major sights in the National Park. Attendees chatted and formed new friendships while Dave Yost pointed out points of interest along the way.

Members of the group shared a picnic lunch at a spectacular rest stop on the Yosemite Valley floor. The view of the mountains looming all around combined with a morning’s exercise in the fresh air to make the sandwiches even more delicious.

After a large lunch of turkey sandwiches and amazing scenery, the Yosemite Tour team walked to the lower Yosemite Falls and posed for group photographs. The poses may seem rather contrived, but the smiles are all natural.

ABECAS Insight Server can be installed on a machine running SQL Server 2005 64 Bit. The following steps are necessary during this operation:

1. Install the .NET Framework 2.0 and all security updates for the framework on your Windows Server 2003 64 Bit or (for testing purposes) Windows XP Professional 64 Bit machine.

2. Install SQL Server 2005 64 Bit (any edition) and Service Pack 2 for that product.

3. Open the SQL Server 2005 Surface Area Configuration Tool from the SQL Server 2005 folder in the Start Menu and click the Surface Area Configuration for Features link at the bottom of the page.

4. Highlight the CLR Integration node and check Enable CLR integration.

5. Create a folder named AI64 on your C: drive.

6. Right-click on My Computer and select Properties. You can also access this information by opening the System applet in the Control Panel. Click on the Advanced tab and click the Environment Variables button.

7. When the Environment Variables dialog is open, highlight the Path variable in the System Variables list box and click the Edit button.

8. Add C:\AI64 to your path using a semicolon, as shown.

9. Download the ABECAS Insight 64 Bit Support package here. Unzip the files from this package into your C:\AI64 directory. The package includes the following:

NTWDBLIB.DLL (DB Library) - This file is necessary for the operation of ABECAS Insight on any operating system.

Argos.SqlXpLib.dll - The C# assembly required by ABECAS Insight on 64 Bit SQL Server.

Custom_Script_For_Sql_Server_64bit_PART_1.sql - Script required for installation of the C# assembly.

Custom_Script_For_Sql_Server_64bit_PART_2.sql - Script required for installation of the C# assembly.

10. Install ABECAS Insight 7.3 or higher.

11. Open the SQL Server Management Studio as SA and connect to your local SQL Server 64 Bit installation. Click File -> Open -> File… on the menu or CTRL+O on your keyboard to open a file. Browse to the location of Custom_Script_For_Sql_Server_64bit_PART_1.sql and open it. Click the Execute toolbar button or F5 on your keyboard to run the script.

note: This script will run against the MASTER database- Do not alter the script so that it runs against another database. The path in the script refers to the C:\AI64 folder. You will have to change this part of the script if you have chosen another location for your 64 Bit support files.

12. Open Custom_Script_For_Sql_Server_64bit_PART_2.sql and change your current database to ABECAS_CS, or another ABECAS Insight database. You must run this script once in every ABECAS Insight database on your SQL Server other than ABECAS_SHIP. Click the Execute toolbar button or F5 on your keyboard to run the script.

You must follow these steps in order to ensure that the ABECAS Insight Server will function properly. In addition, you must perform steps 11 and 12 after any update to your ABECAS Insight system, as the setup program does not yet fully support 64 Bit installation.