Comments by djdynamix (Top 17 by date)

Another update... I've found a temporary workaround in order to get some machines out. (I had to, because I had clients waiting!) It's a bit convoluted, but it works for now.

First I load the kiosk with "Task Manager", instead of as a shell. Within the kiosk software I placed a fairly standard "Hide Taskbar" class, which you can easily find on here or on several other websites to download in C#. I just translated it to VB.Net with "Sharp Develop" and pasted it in. I then made sure that the kiosk called "taskbar.hide()" from that class everytime a window was opened or closed.

To deal with the one app which popped up the taskbar regardless, I then downloaded a freeware app which removes the "Always On Top" feature of the windows taskbar, and used Task Scheduler to run it at every logon. The "rogue" program now pops up the taskbar invisibly behind the kiosk. For anyone who is interested, you can obtain that app from http://www.sevenforums.com/tutorials/54842-taskbar-always-top-disable-enable.html.

Finally, to ensure that the user can't just tab through to the taskbar, I downloaded "Autohotkeys" (another fine piece of freeware) and used it to redirect Alt+Tab, Alt+Esc and a few other hotkey combinations.

I still want to do the job properly, and have my kiosk run as a proper shell with a functioning taskbar of its own, but at least the project isn't stalled until I can.

OK, still researching here. Currently struggling through Arik Poznanski's Code Project article. "C# does shell", which is one of the few resources I've found that even approachmy level of understanding. As I understand it, I have to put my kiosk "taskbar" toolstrip into its own window and register it with the OS as an "Application Desktop Toolbar", so it is able to receive the taskbar calls from the app.

Even though Arik's article is excellent, it's still a little bit above my head, and also in C#. (I'm a VB.Net kinda guy.) I'd be REALLY grateful if someone could check it out and give me a "for dummies" translation, preferably in VB.Net. I don't need his entire project, just the bits referring to calls from top level windows to the taskbar. I do, however, need a bit more than just a VB.Net translation of the code. I can do that myself in "Sharp Develop", but I need to understand what the code is actually doing so I can adapt and implement it.

Thanks again.

Thanks for the info. Out of interest, the best bit of software I've found for turning C# into VB.NET is a Freeware called "Sharp Develop". I've run entire projects through it and not had to correct a single line of code! (It can also cope with F#, J# and Java.)

I finally found out the problem with the USB pendrive serial numbers. There's no industry standard! The particular one that I was using for testing didn't even have one. I've ditched that idea, in favour of having a hashed security file on the machine and pendrive, and a user "key" which must all match. Which bit of the code are you most interested in?

You can get the sample code and info from http://code.msdn.microsoft.com/windowsdesktop/VBWin7TriggerStartService-dcd0e7cf.

To be honest, I've used it pretty much "as is", except for removing the Network ÏP connection stuff and the Microsoft licensing junk.

The link you gave to the service privilege stuff is very interesting. I think it might give me a part of my answer because I didn't realise that my service could be running under "Local Service" instead of "Local System". If it is, then that would explain all the "Access Denied" errors I keep getting.

As I understand it, VB2008, even the pro version, has a few "known issues" when it comes to service programming. Much of the sample code for VB2005 doesn't work, stuff for VB2010 and above uses a completely different .NET package (3.5 & 4.0 are significantly different animals to 2.0!), and things like the service timers have now been replaced with threaded versions which are tricky to get working in anything below VB2010. I finally bit the bullet and downloaded a copy of Visual Studio 2012 Ultimate, which is free for 90 days from the MSDN website.

I've now managed to get the service to recognise when a pen-drive is inserted, and it does it even before logon, so that part is now sorted. I finally did it with the "SERVICE_TRIGGER_INFO" class, which can trigger one service from a polled event in another. Hence, I've effectively nested a service within a service, had the outer service poll for the system event (USB storage device connected) and then trigger the nested service. I don't totally understand what I'm doing with it, as I've copied and pasted much of the code from an MSDN example project, but for now, that bit works!

The problems I now have are firstly to get the service to read the pendrive and secondly to move the user account from "Users" to "Administrators". I thought the latter would be easy, as I could call "net.exe" with the "localgroups" function, but it doesn't work, due to the fact that the service is running in a special "System" account, which can't natively run console apps. I tried using "Active Directory" to do it, but I keep getting "Access Denied" errors. Frankly, at the moment, I'm stuck!

Later tonight, I think I'll post a more specific question about how to change local user permissions with a service.

Oh, btw, an Administrator account is always declared in both the Administrators group and the Users group. By deleting the reference in the Administrators group, it automatically falls back to a standard-permissions account. Only by deleting it from the Users group do you lose the account altogether.

I take your point, ledtech, but there is always the fall-back of the inbuilt system Administrator account, which can be accessed through safe-mode. What I'm trying to accomplish here is a single, straightforward boot process which happens (automatically) in different ways depending on whether an authorised pendrive is detected. I should also mention that all the systems are identical, with no important user data on them, and, in the event of a catastrophic failure, the fix is merely replacement of the hard drive with a stock clone and reactivation. Hence, if we lose access to the Admin accounts, it just means a 20 min trip to the workshop at some convenient time before the next planned update.

Aha... I think I've got it! A command-line function, "net localgroup", which can be run from any elevated account. If I can get a service to start on boot and before logon, it can poll the USB ports for a pendrive with the correct encrypted key. It can then use "process.start" to call "net localgroup "username" administrators /add" and turn the regular client account into an Administrator account prior to logon. When the USB key is removed, the service will then call "net localgroup "username" administrators /delete" to restore the account to Standard User. It will have to do a bit of other "housekeeping" as well, like toggling the "Removable Storage\DenyAllAccess" DWord in the HKCU\Policies hive and creating a few necessary log files and registry keys, but that is stuff I've already coded.

If I get it to work, I'll stick a bit of sample code below in case anyone else ever needs to do anything similar. Otherwise, expect more questions from a guy with less hair! ;-)

PS: In case you were wondering, the "Win Explorer" button is removed from the desktop before deployment, and the "Admin" button is passworded and hidden.

No problem, ledtech. We all make mistakes, as the hedgehog said to the toilet brush!

Anyway, for the sake of interest, the user desktop looks like this> http://i1053.photobucket.com/albums/s477/IanMcKenzieAnderson/KioskDesktop.jpg

As you can see, there's not much to it, but it still caused me problems when we started implementing Win7 SP1, because it was running as an explorer-replacement shell, in a reduced-privilege environment, trying to write its settings to %ProgramFiles%, and I didn't have the source code to move the settings files and logs to %AppDataLocal%!... File-Write-Permissions-Hell again! As it happens, my next job after this system management software (or maybe even as part of it...) is to rewrite that App Launcher and bring both the code and the "look" up to date. It's actually a bit more complex than it looks, as it is driving an extended desktop with rolling backgrounds on Display 2. The rental systems are intended as complete bar/venue entertainment systems with Karaoke, Video, Background music, Bingo, Pub quiz and rolling advertising, all in one box with a simple point/click interface. All the bars have different TV systems, so the installers need access to the Screen Resolution settings, some of the clients moan if they don't have the latest top 40, so the updaters need access to the mp3 files (and access to an open USB port to update them), and we're doing the whole thing on an island (Tenerife) where the power stability can be worse than 3rd world, so all of us need a one-button system-restore (ours, not Microsoft's) for when the voltage spikes in the middle of a disk-write!

The problem with code which changes system settings in the registry is the same one I've had all along, and that is that, as far as I know and have experienced, it will fail with "Access Denied" under a standard Windows Account, even when "Run As Admin". I need something which will run like a service with elevated permissions prior to logon and either enable and open an Administrator account, or apply Administrator permissions to the existing account.

I don't suppose you know where Windows 7 keeps its Account User Type switches? If I could find those in the registry, I could just raise and lower the main account's user type with a service on boot-up.

Thank you for all your input, everyone. Have to say, TCP has some of the most helpful members on the net! :-)

Anyway, Zoltan and Sergey, I looked up the Smart Card login idea on MSDN. It's a HUGE topic, and probably a bit above my head, but worth following up, especially given that I have a part-time collaborator on the project who is a software security specialist who will probably know what things like "ECDSA logon requires an associated ECDH key" means!!! (Unfortunately, whilst he is a total wizard with security protocols, he tends to be more at home in proprietary OS's than in Windows, so Win7 logon issues will be down to yours truly.)

In theory there would be nothing to stop us using cards instead of pen-drives, so long as the cost of the necessary hardware isn't prohibitive. (Remember that anything we install to the machines, we'll need 50 off, so the card readers will need to be cheap as chips!)

Another option sprang to mind having read ledtech's comment. That would be a service that ran on boot-up, prior to the Windows Logon screen, which switches the regular account from Standard to Administrator when it detects that an authorised pen-drive is present. That way, everyone (clients and staff) would log in to the same account, but staff would be logging in with Admin privileges. I wonder if your sample program could be adapted to acheive that, ledtech?

Just an addendum here. I want the whole login process for both clients and authorised staff to be as simple and automatic as possible. Ideally, the fact that the pendrive is installed would just take the user straight to a login/password form, and then to the Admin desktop. The only person who'll be accessing those machines with any amount of "computer savvy" is me. The other staff are really no more than data-entry guys. The perfect solution would be one where a "licensed updater" (which is what I've called them in the software logon form) will put a pen drive (or a card), which I've previously prepared, into the machine before booting it, switch it on, enter their login and password and simply be asked "Do you want to update or restore - Y/N"! (There is a bit more to it than that, because there are also buttons to cope with different screen resolutions and stuff, but the bottom line is that I need it idiot-proof.)