hot potato workers
-
@jasgot said in hot potato workers:
@dashrender said in hot potato workers:
Another idea is and RDS setup.
My biggest concern about this is the scanner. I have no idea if it will work in a multi-user environment like RDS. In fact I doubt it will since it won't work in a multi-user environment like Windows 10.Have you considered TS Scan by Terminal works? https://www.terminalworks.com/remote-desktop-scanning
We use it for RDP scanning from remote USB scanners and it works great. You can test it for a trial period to see if it will handle multiple clients to one remote scanner. I think it will; one at a time.
We have an insurance card scanner at each desk. I don't see this changing.
In fact, if anything - there have been discussions for years about adding a full size page scanner at each station. The biggest hold back on this is space. our primary location's front desk barely has enough room for the keyboard, mouse, phone and a cup of coffee. the insurance card scanner is crowded up under the monitors and pulled out when needed.
-
I keep thinking about this. It's the kind of problem I love to tackle.
If the scanner redirector from terminalworks does indeed allow you to use the scanner with you insurance/single use issue, then mandatory roaming profiles may work well for you.
BTW: for some reason, I think the termnalworks software disconnects the link to the scanner if the RDP session goes into a disconnected state. This should work well for insurance/one user issue.
-
@jasgot said in hot potato workers:
I keep thinking about this. It's the kind of problem I love to tackle.
If the scanner redirector from terminalworks does indeed allow you to use the scanner with you insurance/single use issue, then mandatory roaming profiles may work well for you.
BTW: for some reason, I think the termnalworks software disconnects the link to the scanner if the RDP session goes into a disconnected state. This should work well for insurance/one user issue.
Personally - I'm not a fan of the RDS solution - it's so expensive.
I'd like a solution at the desktop instead... not sure I'll get one, but it's where I'm currently trying to aim.
-
@dashrender said in hot potato workers:
@jasgot said in hot potato workers:
I keep thinking about this. It's the kind of problem I love to tackle.
If the scanner redirector from terminalworks does indeed allow you to use the scanner with you insurance/single use issue, then mandatory roaming profiles may work well for you.
BTW: for some reason, I think the termnalworks software disconnects the link to the scanner if the RDP session goes into a disconnected state. This should work well for insurance/one user issue.
Personally - I'm not a fan of the RDS solution - it's so expensive.
I'd like a solution at the desktop instead... not sure I'll get one, but it's where I'm currently trying to aim.
Will the scanner work in the following scenario?
- User A logs in and scans
- User A locks the screen and goes away
- User B logs in
- User B unplugs the scanner physically and then plugs it in again
- User B starts working and scanning
Do you think what I'm thinking?
-
Will the scanner work in the following scenario?
- User A logs in and scans
- User A locks the screen and goes away
- Computer goes to sleep
- User B wakes it up and logs in
- User B starts working and scanning
-
Is it possible to run a script with admin rights that terminates the scanner software when a new user logs in?
-
@dashrender said in hot potato workers:
We have an insurance card scanner at each desk. I don't see this changing.
Not sure how to read this response.
TSScan is software not hardware. It will allow a session on an RDP server to see that locally attached twain scanner. But RDP is not an option. (yet!) -
Having spoken to @Dashrender just yesterday about the environmental differences between his org and mine - it's amazing.
We use the same EMR, just accessed differently. very very differently. So we have the same issues, do a differing level, application wise,.. network/computer wise - we are 10x more involved. (would you agree @Dashrender )
His org goes direct, whereas we use RDS. And there are a number of other differences. We use the AmbirScan card scanners and TS Scan on the desktop to the RDS session. We also have nearly fifty printers and and Zebra printers. Our RDS Pool is suspended over night for cost. Everything is across a VPN...
-
@jasgot said in hot potato workers:
But RDP is not an option. (yet!)
in
hisenvironment - I don't think RDS would ever be an option. The infrastructure changes needed are quite involved. -
@pete-s said in hot potato workers:
@dashrender said in hot potato workers:
@jasgot said in hot potato workers:
I keep thinking about this. It's the kind of problem I love to tackle.
If the scanner redirector from terminalworks does indeed allow you to use the scanner with you insurance/single use issue, then mandatory roaming profiles may work well for you.
BTW: for some reason, I think the termnalworks software disconnects the link to the scanner if the RDP session goes into a disconnected state. This should work well for insurance/one user issue.
Personally - I'm not a fan of the RDS solution - it's so expensive.
I'd like a solution at the desktop instead... not sure I'll get one, but it's where I'm currently trying to aim.
Will the scanner work in the following scenario?
- User A logs in and scans
- User A locks the screen and goes away
- User B logs in
- User B unplugs the scanner physically and then plugs it in again
- User B starts working and scanning
Do you think what I'm thinking?
Not likely - because the software is still actively running under user A
-
@pete-s said in hot potato workers:
Is it possible to run a script with admin rights that terminates the scanner software when a new user logs in?
Now there's an idea...
So -
User A logs in - locks
user B logs in - script kills software, software auto relaunches - user b locks.The question is - when user A logs in again - is that seen as a new user logging in? or just a resume of previous session? If the script can be made to run every time, this would be a possible solution to that specific issue.
-
@jasgot said in hot potato workers:
@dashrender said in hot potato workers:
We have an insurance card scanner at each desk. I don't see this changing.
Not sure how to read this response.
TSScan is software not hardware. It will allow a session on an RDP server to see that locally attached twain scanner. But RDP is not an option. (yet!)The insurance card scanner is not a twain device. It's it's own connection over USB (so far as I understand) - to TSScan wouldn't work for the scanner anyway.
-
@gjacobse said in hot potato workers:
Having spoken to @Dashrender just yesterday about the environmental differences between his org and mine - it's amazing.
We use the same EMR, just accessed differently. very very differently. So we have the same issues, do a differing level, application wise,.. network/computer wise - we are 10x more involved. (would you agree @Dashrender )
His org goes direct, whereas we use RDS. And there are a number of other differences. We use the AmbirScan card scanners and TS Scan on the desktop to the RDS session. We also have nearly fifty printers and and Zebra printers. Our RDS Pool is suspended over night for cost. Everything is across a VPN...
yeah - Frankly your situation just sounds weird to me, but not unheard of considering that you can get Azure on-premises.
Gene's environment appears to be a singular session running in Azure, not a cloud session like mine.
Gene's company then uses RDS sessions in Azure to grant access to their users.
As Gene mentioned, there is a VPN between his office and Azure allowing local printers direct IP printing from the RDS sessions, and his client workstations to access those RDS sessions.
Gene also mentioned that the performance of their athena in this manner is significantly better compared to accessing athenaNet directly from their devices in their office via the internet.But my question is - what is the cost of this setup? I'm guessing 10's if not 100's of thousands of dollars a year on top of the athena cost itself (which is significant).
-
@gjacobse said in hot potato workers:
@jasgot said in hot potato workers:
But RDP is not an option. (yet!)
in
hisenvironment - I don't think RDS would ever be an option. The infrastructure changes needed are quite involved.Well - I'm the one who tossed out the idea of using RDS/RDP in the first place for this particular situation.
And since your ambir scan's are working withe TSScan, we could switch to those for the insurance card scanning if the solution fit within our requirements.
-
athenaNet recently added the ability to do direct scanning from within the chart (before that, the only option was - scan to a file, then upload that file through the uploader). using either TWAIN compliant or Snapscan scanners.
Sadly as mentioned repeatedly above, athena specifically blocks the use of network attached twain scanners.
Making matters worse, the process for getting an insurance card into athena is yet another process.
The insurance card is scanned (typically using Inuvio or Ambir scan software) to c:\card\cardab.jpg.
The athena add-on software (athena device manager) will - when the correct button is pressed inside athena - look to that directory and if a file is there by that exact name - check how old the file is. If it's more than 5 mins old - it will warn the user that this file is more than 5 mins old and are you sure it's the correct one? - assuming you choose upload anyway - the jpg is uploaded into athena.This process makes it extremely painful to use a single device to scan files AND insurance cards into athena from a single device. In the case of scanning, the twain driver is used. in the case of the insurance card - local scanning software must be used to place the image into c:\card.
-
Okay. Let's look again at the idea of a script to kill and restart the software. Once you have a script working that can kill the software on demand, and start the software on demand. move the script to a GPP.
Use GPP (Group Policy Preferences) to create scheduled tasks that uses the "On workstation lock" and "On workstation unlock" event to trigger your script.
-
@jaredbusch said in hot potato workers:
@dashrender said in hot potato workers:
This also solves the Lastpass situation, as once it's setup under the shared user, it should just remain there.
But it won't be logged in to the right user.
Browser sessions won't be the right user.
Just an all around bad idea.
I'm back to working on this for a bit and re-reading the thread.
The browser would be set to clear cache upon closing and LP would be set to log out upon closing.So browser sessions shouldn't be an issue for either LP or any of our web apps.
-
@dashrender said in hot potato workers:
@jaredbusch said in hot potato workers:
@dashrender said in hot potato workers:
@jaredbusch said in hot potato workers:
@dashrender said in hot potato workers:
This also solves the Lastpass situation, as once it's setup under the shared user, it should just remain there.
But it won't be logged in to the right user.
Browser sessions won't be the right user.
Just an all around bad idea.
LP will be set to log out upon the browser closing -
There's only so much I can do for the users - They have to log out of Outlook, they have to log out of athena - they need to close the browser or log out of LP... so that's really not a big concern in my mind.
IF - IF they can log out those things.. this is not an issue. tons of places use shared computers with the full expectation that once you are done YOU will log out when finished to prevent the next person getting access to your crap.
Force Edge to always use porn mode. That should help.
that helps as long as the browser is closed when the user is finished -
an additional concern here is getting add-ons, like Lastpass, to work in porn mode.
-
@jasgot said in hot potato workers:
Okay. Let's look again at the idea of a script to kill and restart the software. Once you have a script working that can kill the software on demand, and start the software on demand. move the script to a GPP.
Use GPP (Group Policy Preferences) to create scheduled tasks that uses the "On workstation lock" and "On workstation unlock" event to trigger your script.
Good idea - though I'm guessing logon is not the same as workstation unlock, so I'd need a third option there for a new user logging in while the station is locked for a previous user.
-
Something new I just discovered, M365 Business Premium includes Azure Virtual Desktop.
I need to dig into this more, but if it's what I think it is, and RDS session, This lower price might make it make sense to use.
