strawberry7

Hi John, Thanks for the response. I wanted to contact you directly about this but could not find your email and it was a bit long for Twitter! I understand your points, however the information back in June did not specifically say that you were going to remove this ability. As mentioned in my other posts, some notice would have given support companies and schools some more time to prepare and ensure staff mobile compliance. I am more than happy to provide feedback on the Atomwide services and LGFL. You can reach me anytime on 01252 279777 or [email protected]

Hi, I understand your points, however my main point was actually the lack of notice of the change. If we had been notified about this a few months ago, it would have given us time to prepare the schools. The password match I mentioned is done automatically via USO Sync. I agree it is not the best idea but if you provide users with too many passwords, they write them down and stick them to their computers, put them in a drawer, etc - a worse situation I am sure you would agree. That is the real world situation of what people do. It is therefore sometimes the lesser of two evils to standardise as much as possible. Consider being able to sign in to platforms with your Google or Facebook account for example. You are, in affect, creating a single login with single password. I realise there are extra security layers when using this system but the principle is the same. Whilst I do also agree with your point about user accountability, our support requests are all recorded and tracked through our support desk. It is therefore recorded when we are working with a user or their machine and the school understands this. I do not believe it creates an idea of sharing passwords. An approved, trusted support engineer, who administers your computer, being able to have access to your password is different to giving it to another staff member. Test accounts are fine but there are instances when specific user related issues need troubleshooting and ensure that it works for the exact user in question is preferable. Do you administer LGFL yourself?

Hi, It has been a long time since I posted on here. I was wondering what you all think of the LGFL change that happened today regarding staff passwords. Traditionally, LGFL have always allowed approved support and nominated contacts to view passwords for staff. This allowed us to issue new passwords to the staff. If the USO Sync was in place, it also meant we could login as a staff member without having to disturb them to check their machines. LGFL have now taken this ability away - citing GDPR compliance. I take issue with this for 4 reasons: 1. We did not receive notice that this was happening. I am asking LGFL if any was issued. 2. I am no GDPR expert but I have spoken to a few. I do not believe that having the ability to see users passwords was a breach of GDPR. GDPR is all about informing people what is happening with their data and protecting it as much as possible. It would actually be more relevant to hide the staff mobile numbers for example. As long as the staff are aware that we have the ability to see their passwords, then GDPR compliance should be met. Also it probably would have been better to give staff the ability to hide their passwords from support should they wish. 3. In the real world, this change is very impactful. An example is that during half term we are undergoing a change (coincidently LGFL related) at one of our new schools. During half term we are wanting to check various computers and teacher logons. This is now not possible as we cannot see their passwords and the staff are not contactable during half term. Any resets of passwords are going to the staff mobiles and we will not be able to access them. 4. LGFL have stated that 'In order to make it simple and efficient to reset staff passwords we would encourage staff to verify their mobile numbers.' Again, there has been no lead-in time to set this up or prepare. I would be interested to hear if you are affected by this change and what your thoughts are.

Try making your own manual shortcut. A good way of making the shortcut is to use the %programfiles% switch. This will mean that if you have a mixed 32 and 64 bit environment, you will not have a problem deploying universal shortcuts. In case you don't know, 32 and 64 bit environments can wreak havoc with shared shortcuts as 64 bit programs have C:\Program Files and C:\Program Files (x86). Hope that helps.

Haha, you beat me to it!

I would not be surprised as LGFL/Atomwide's official stance is - all remote tools except RAV3 and CentraStage are blocked and unavailable. Apparently they are working with LogMeIn to try and get it using the USO system but that is the only 3rd party discussions I know of.

Thanks for your input but as I mentioned in my post, the subnet change happened only a few days before migration. Ww changed our subnet because we simply didn't need to separate our admin anymore, we just have 1 server with 1 domain and 1 network, much simpler. Also I couldn't remote desktop because there was no internet connection into the school. I was just saying that Logmein used to show you how long a client had been off for, which was really useful. As for them updating the support case, yes they did but it was already done by then. I am not in 1 school all the time and I don't have the luxury of always being able to jump when something happens in LGFL land. I went on the training course. The trainer was great, the course was well organised and the facilities were good. Unfortunately it was exactly as I expected, 10% golden nugget info and the rest was totally irrelevant for me. I could have just looked at the last summary slide and got all the information I needed. I still stand by what I said about it being complicated, I still think the GUI needs a lot of work, I still think they should have been more up front about it at contract signing, I still think it is unreasonable to block remote login tools and I still think that rav3 is a poor substitute. I did have some interesting chats about other stuff though, for example we were discussing the fact that you have to close a browser to complete log off requests. I voiced that I found it strange with all this focus on security a process like this was in use. Apparently this is due to shibboleth or whatever it's called and they are trying to get it changed but obviously it's out of their control. Hopefully it will be changed in the near future.

Thanks again for the info, I don't want to draw this thread too much off topic but this is really interesting and I totally agree with what you're saying. It's the same reason that engineering projects take so long I guess, people so worried about whether somebody might chip a nail, the work doesn't get done.

Wow, security is an area that drives me mad and an area that I have limited knowledge in but am always interested to know more. Thanks a lot for the info!

Well this morning my LGFL 2.0 site went offline with no internet access. I couldn't access remotely and, unlike Logmein, the remote system didn't tell me how long the server had been unavailable. I originally submitted our IP information a long time ago and it had very recently changed, including us ditching our admin range. The firewall had been setup such that the admin range was on port 1 and the curriculum on port 2, therefore port 2 was the one physically in use to our network. I had submitted an IP change request and this had been done but nobody thought to tell me that they had moved the curriculum to port 1 due to the removal of the admin IP range. This meant that the internet went down due to the fact that the network was still physically connected to port 2. Luckily I was around the corner and the school was only offline for 45 minutes or so this morning, annoying that they didn't tell me though and that they didn't think to schedule the change with me. Not to go over old ground or anything but if I was still allowed to use Logmein, I would have seen that the server had been offline for the same time that the support ticket had an update on and piece it together before even arriving on site. I also would have been able to check on my iPad on the way to work and let them know when they phoned that indeed there was something wrong that would affect the whole network and it wasn't just that users computer. I will hold my hands up and say that I could have changed the IP range before installation but the change was made on our end only about a week before the install and I just hadn't even thought about changing it on the LGFL part. I have already hit the remote functionality restrictions in the first week of LGFL 2.0!

I find this interesting. So is there no distinction in the law between images being 'distributed' automatically by a technology system such as caching and you deliberately transferring such images from one form to another which requires a human input?

Well done finding it. I will keep this in mind myself as I am not very familiar with papercut but we do use it here.

If you're happy to give your user local admin access to the machine then that might sort the problem. You can do that by logging in as the admin, right click my computer, go to manage, go to local users and groups and then add the network user name to the local admin group. I give all of my staff local admin access so that they can install programs and it sorts a lot of problems. Sometimes they accidentally install rubbish but very rarely and it certainly solves more problems than it causes.

I am not refusing point blank and I have fully explained my points about that earlier.

Extremely annoying! I had a situation yesterday where a teacher was trying to move folders on a windows 7 machine and it said that the folders were in use by another program. Which was rubbish as even after a reboot it was doing the same thing. I used unlocked and it moved the folders immediately lol.