We've had SysAid for a little over a year, but haven't fully rolled it out. Mostly just been using it's Projects and Tasks module for tracking testing for a new software update and the Asset component for pulling software/hardware info. An issue was reported with SysAid performance and freezing while importing the tasks for a new update. Hmmmm, that didn't sound good.
Our original deployment was using the included Derby database, but decided to switch when we were having performance issues with the Projects module. We have roughly 1500 assets that SysAid keeps track of, so the discovery and deployment modules are pretty busy.
When I heard about this new issue I decided to dive into the Tomcat logs to see what was up. Lo and behold I found a bunch of errors such as...
"ERROR com.ilient - ConnectionPool: ilient pool is full. waiting too much. giving up..."
Sounded a little like the queue to access the database was a little like the line outside an Apple store when a new iPhone is released.
Checking the serverConf.xml file settings for the database showed me the following...
10
10, methinks that sounds a little on the low side. Off to do a little web search and I came up with this thread that gave me some hints that this configuration was lacking in our case. Bumped the dbPoolMaxConn up to 100 and restarted the Sysaid Server service, and kept an eye on the Tomcat log file. I haven't seen a recurrence of the error and the end users have reported that performance has improved.
Sounds good to me, now on to my next issue ;)
UPDATE: While dealing with an entirely different issue SysAid Support Engineers had me bump this field up to 200, so again depending on how large/busy your deployment is you may want to increase this field to add more traffic lanes into your database.
[ Photo: Kaptain Kobold ]
Our old backup PACS web access system is no longer supported and the hardware you can't even find replacements for now, so we were looking at some Open Source alternatives and specifically at DCM4CHEE PACS Server. For evaluation purposes we downloaded the CDMEDIC Live CD of DCM4CHEE (based on Ubuntu 11.10) and deployed it as a virtual machine.
The information on the DCM4CHEE Wiki is quite valuable for setting up the modalities that will be pointing at it and for tweaking the configuration. By default the Live CD deployment is configured to listen for DICOM traffic on port 11112, so you can just set your modalities up to point at the IP of the DCM4CHEE server and port 11112.
The server's web interface is accessed by going to http://yourserversip:8080/dcm4chee-web3/ and the default login is admin with the password of admin. From here you can run a search for any studies that have been uploaded to the server, configure Application Entities (the modalities that will be sending to it) and HL7 feeds that will be feeding your modalities worklists. I haven't got that far with testing yet but sending from the modalities works fine.
The Live CD has the Weasis viewer installed by default and seems to work quite well, though the mouse controls for image manipulation take a little getting used to (at least for a SysAdmin).
I've been working on getting it to authenticate back to Active Directory using the information provided in this forum post and am able to log into the web interface correctly with my Active Directory credentials but then the modalities are unable to send to it. It's a JBoss application so I've been perusing the documentation on the LDAP authentication module, but no luck just yet. All I need is time :)
There is a new version being developed (version 4, the Live CD is based on the version 2 branch) that will have LDAP Authentication built in, looking forward to it. The DCM4CHEE PACS Server definitely looks like it will do the trick for providing us with a backup PACS system once I iron out the LDAP piece.
I found myself needing to move a certificate from our old Exchange 2003 server to our new Exchange 2010 Hub server and found that the particular certificate was showing that the private key was not exportable. Hmmmm, that created a slight issue. Off to do some research and I found a tool that was able to accomplish the task.
Mimikatz is a pretty handy tool, though a little lacking in English documentation. A short download later and I was off to the races.
It comes with versions for Win32 and x64, just run the 'mimikatz.exe' in the appropriate folder with administrative privileges. When it opens you're presented with a command type window into which you enter...
An export of the systems certificates will be saved to the folder you ran the executable from in both DER and PFX certificate formats, the PFX files will have 'mimikatz' as the password. You can now happily take the certificate you need to the system you need it on and import it to the correct store.
I've heard that it works for Win8 as well, but haven't tried it. The tool has some other less desirable features (at least less desirable if you're concerned about system security), a web search will bring up a number of posts but at least you need administrative privileges to run it. If you find yourself needing to Export Non-exportable Certificate Keys you should check Mimikatz out.
So I had a user that was unable to open links in Outlook, they encountered the following error after they downgraded to Office 2007 from 2010 and tried to open links within emails...
This operation has been cancelled due to restrictions in effect on this computer. Please contact your system administrator.
Looks to be an issue with the Default Program settings for opening internet links, so Outlook doesn't know what to do with it.
The resolution is in kb 310049 from Microsoft. Click on the FixMe button for the appropriate OS and after a quick reboot you're back in business, or if you're into fixing it manually the instructions are there as well.
You can take the Geek out of his element, but you can't take the geek out of the Geek.
Getting back to the Active Directory Export to our Learning Management System, after importing the Managers into AD I added the manager field to the export as seen below.
$Date = (Get-Date -format "dd-MM-yyyy") if ( (Get-PSSnapin -Name Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue) -eq $null ) { Add-PsSnapin Quest.ActiveRoles.ADManagement } get-qaduser -SearchRoot 'domain.local/Users' -enabled -dontusedefaultincludedproperties -includedproperties sn,givenName,sAMAccountName,employeeNumber,telephoneNumber,mail,title,manager -SizeLimit 0 | sort-object | select-object sAMAccountName,employeeNumber,givenName,telephoneNumber,title,sn,mail,manager | export-csv -Delimiter ',' -NoTypeInformation -Path \\ServerX\LMS\LMS_export$Date.csv
Slight issue is that the 'manager' field in AD gives the container of the manager's account, LMS vendor can't work with that and wants the sAMAccountName for the manager. Hmmmm, ok.
After some more poking around for a solution I came up with something that...
The following is what the script looks like...
$Date = (Get-Date -format "dd-MM-yyyy") if ( (Get-PSSnapin -Name Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue) -eq $null ) { Add-PsSnapin Quest.ActiveRoles.ADManagement } $users = get-qaduser -SearchRoot 'domain.local/Users' -enabled -dontusedefaultincludedproperties -includedproperties sn,givenName,sAMAccountName,employeeNumber,telephoneNumber,mail,title,manager -SizeLimit 0 $users | Add-Member Noteproperty -Name ManagerSam -value $null foreach ($user in $users){ If ($user.Manager -ne $null){ $user.ManagerSam = (get-qaduser -identity $user.Manager).samaccountname } } $users | select-object sAMAccountName,employeeNumber,givenName,telephoneNumber,title,sn,mail,managersam | sort-object sAMAccountName | export-csv -Delimiter ',' -NoTypeInformation -Path \\serverX\LMS\LMS_ad_export$Date.csv
Works like a charm and doesn't take forever to run. More importantly it gives our LMS vendor what they need to have their software function correctly. And that’s a fabulous thing! :)