kennysarmy

Well thankfully both daughter and I continued to test neg. over weekend so she's now started her army career at Pirbright - they also did another LFT when we dropped off. Track and trace contacted me so as a precaution also went for PCR last night, but LFT this morning again neg. Mrs KA very upset not able to hug daughter before she left home - and has now lost sense of smell All in all an emotional last 5 days.

I'll try adding as "authentication exception"!

Mrs KA LFT +ve last night She was awaiting PCR test having spent most of Saturday with someone who subsequently tested +ve on Sunday. PCR came back this morning "inconclusive" so another one booked for this morning. My LFT last night was -ve. Meant to both be taking daughter to start "basic training" on Sunday - that's now in jeopardy Bit of a nightmare.

Needless to say they've not phoned back so I guess I'll be chasing next week

Not surprised that's the advice from SIMS support company, but there surely is no reason why it wouldn't work. As has been said - just snapshot the VM first and test after.

It mentions Gmail being affected - so does that mean M365 is OK? >>> Scan to Email: will be impacted if using gmail for SMTP.

This?

No report that it's not working here...

Installing and testing as domain admin. Get same error when opening on PC logged in as local admin. Firewall on local PC off. Smoothwall not blocking any traffic. App Policy rules updated to not block C:\Users\Public\Surpass\SecureClient Sophos also not realtime checking : C:\Users\Public\Surpass\SecureClient

If only I could get passed the Clipboard error

Tried on another PC and getting the same error. Phoned them on (0)1274 203270 and they are going to look in to it :/

Accepted it can only install to the default location. Now opens but with this error:

I've just been lumbered with getting this to work. Downloaded the MSI : SecureClientInstaller.msi From : https://admissionstesting.surpass.com/LaunchTest Their website states you can set an installation directory using the code : msiexec.exe /i C:\SecureClientInstaller.msi CMDLINE=/DEFAULT_INSTALL_DIR="C:\SecureClient" /qn I've edited this as follows: msiexec.exe /i "Q:\SecureClient\SecureClientInstaller.msi" CMDLINE=/DEFAULT_INSTALL_DIR="C:\Program Files\SecureClient" /qn It just pops up the standard MSIEXEC help box If I just run : msiexec.exe /i "Q:\SecureClient\SecureClientInstaller.msi" it does start the installation. If I run msiexec.exe /i Q:\SecureClient\SecureClientInstaller.msi CMDLINE=/DEFAULT_INSTALL_DIR="C:\Users\Public\Surpass\SecureClient" /qn - nothing happens. What am I doing wrong? msiexec.exe /i C:\SecureClientInstaller.msi CMDLINE=/DEFAULT_INSTALL_DIR="C:\SecureClient" seems to work - :/

There is always the poacher turned gamekeeper option!

You joined this forum when you were 11????

It won't matter what you say.

Thank-you. We might consider this for our new school which won't have a local AD - so might work well.

I wondered if anyone was using the Office365 Integration product from Bromcom in a secondary school and how you were finding it?

It's very rarely black and white and what works in one school may not work so well in another.

Thanks for that

If a site returns the block message : The server's certificate has expired - is it unsafe to unfilter? Staff apparently can't live without "https://cooltext.com/" - but it's returning the error for us...

Yes, shared device licence for 365. When it breaks...

Local firewall is turned off - so not applicable in this case but thanks for suggestion.

Thanks for your reply. Sadly I think this is a PC issue rather than user, as I can logon test users elsewhere fine, it's just this one PC that's got messed up. I know I will end up re-imagining it but wanted to try and understand the process of why it was broken Microsoft have looked at it and basically said as long as the users can sign in manually that's fine. Even though they are auto-signed in on all 800+ PC's on the domain, which points to something not right with this one.

Strange issue which I can't get to the bottom of. Teacher alerts us when she opens WORD (and other office apps) that she gets a banner saying the app is unlicensed. We confirm issue and delete local profile, in the hope it's isolated to that one teacher. Issue remains on relogon. We uninstall and reinstall Office. Issue remains on relogon and we see new accounts logging on have the same issue. Our domain account logon - works fine! Bring the PC back to our office for further investigation. Take a test teacher account and replicate the issue. Promote test teacher account to domain account - put in same part of AD - make account identical to domain admin account - issue remains. If we sign in to office then it does clear the Unlicensed error banner - but all other PC's on the network auto sign users in and don't get this issue. Teacher does not have issues on other PC's, test user does not have issues on other PC's. Microsoft remote on to PC and suggest some registry changes which make no difference. I know I could just re-image the PC and I'm 99.9999% sure that will fix the issue, but I'm intrigued now as to what it is on this PC that's now signing in users correctly when office apps open AND THEN WHY - one domain account is not getting the same issue. I did try running fiddler when logged on as the elevated test account and nothing seemed to be being blocked. (I expected this as surely a filter block would affect all PC's / Users) For working users on other PC's a licence folder gets created in C:\Users\\AppData\Local\Microsoft\Office\16.0 But on this PC that folder doesn't get created when they first open say WORD. Also tried removing the PC from the Domain and re-adding. Any thoughts gratefully received.