Michael

Hi all, So the Local Authority have shifted from Egress > Microsoft Message Encryption (OME), but viewing messages is somewhat problematic. Opening the OME email, it displays a blue button. Clicking this then sends a onetime passcode and the email's then viewable as normal. If the user then closes the email and retries the email at a later date, it displays an authentication error, despite it reading "accessible until December 2020" (so months ahead). Is this typically normal behaviour or something the LA need to tweak their end? Many thanks!

Another thing to try (from previous experience) is to download upgraded firmware to a flash drive. This can make all the difference too. Plug in the flash drive with the screen off and press/hold the power button for 10-15 seconds. The MS-DOS upgrade screen will appear with a progress bar and then restart.

Learn something new - still extremely rare though!

You can either do select users or the whole Azure tenancy. Then whatever the selection into G Suite. What happens if you have existing users in G Suite, or manually create users in G Suite - I'm not 100% sure, but I see no issue so long as they don't match. If they did match, I'm not sure what happens in this scenario.

Azure remains the ID Provider and they're bound by a certificate. I can only presume it's a hashed token that's sent to G Suite?

Forgive my ignorance, but I've never quite understood why Wonde's required for Google Classroom. The first time a user signs in, they add the unique class code. Subsequent logons they just sign into Google Classroom and complete work assigned.

The 3.5" format's on its way out, but the 2.5" functions exactly the same. Another example are SSDs - I've only ever seen 2.5".

If you've provisioned users from AD > Azure > G Suite or just Azure > G Suite, it'll work signing into a Chromebook. Linking Azure to G Suite will provision real Google accounts so you can login to any Google service.

It's unfortunate, as RSAT with delegated rights would be perfect for this.

Not an MSI, but this Startup script works fine: @echo off reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{6BBAE539-2232-434A-A4E5-9A33560C6283} if %ERRORLEVEL%==1 goto installer if %ERRORLEVEL%==0 goto noinstaller goto end :installer "\\Server\Share\GoogleFS\GoogleDriveFSSetup.exe" --silent goto end :noinstaller goto end :end

Yes - Seen this before on Kyocera drivers. Right click the printer and selecting 'Printing Preferences' At the bottom left it'll display either PCL5 or PCL6. Click this and then untick 'GDI compatible mode'.

Hi all, Was wondering if anyone else has observed this behaviour - Users in AD are synchronised to Azure, then from Azure to G Suite. Users can authenticate in Windows and Office 365 without any issue. If said user then tries to authenticate into G Suite, it won't authenticate the user. Sign in as Google Admin and the user's there (as expected), with the accent in their first or last name (such as é) ============== If I then return to AD and remove the accent from their first or last name, wait for it to all synchronise, magically the account then authenticates in G Suite. Not sure why this would be, as the accent's not in there username or email address, only their first or last name (which should have no bearing). Any ideas, unless it's a bug?

Morning all, Finally got to the bottom of both issues (for reference): Within Groupcall Xporter > Misc, there's an option labelled "CMIS - Dataset SetId used to override .CDB value". As the name suggests, if you override the setting here (despite changing/updating Facility Controller) Groupcall XPorter will continue to export in the previous academic year. The second issue (different school) was a TLS mis-match. The copy of Groupcall was stuck on TLS 1.1 instead of TLS 1.2.

Yes - I've had someone else report the same and I suggested they respond to the email for a resolution/clarification. Interestingly the password was sent in a separate email

I can only presume the whole configuration is stored on the drives if you swapped out the motherboard.

It kind of reminds me similarly to the way HP and Dell servers work. The RAID configuration is stored on the drives themselves, in the event you needed to change the controller.

I still use LTSB 1607 and LTSC 1809 where required. The next big update I'd look at is the new LTSC when released in 2021.

If you're talking about user data or shared areas, why not just operate from within File Stream? Once it's up there, everyone has an Explorer interface so the learning curve's small. Uploading is a big task, but day to day, personnel are only accessing small parts of the whole data share. If you're talking about archiving, the only other limitation is 400,000 objects - consider an object a file or the folder itself. A singular file can be no larger than 5TB.

I think I might have fixed the Groupcall issue. Looking at the ePortal service, I changed the permissions from "Local Service" to domain\administrator and now all Groupcall jobs appear to be working normally. I'm not sure whether this problem has been caused by a Microsoft Update?

Thanks - just spotted there's a new Facility 20.3 release (currently running 20.2). I've had Groupcall look at it and everything looks normal, just missing new Y6's when performing a debug.

Hi all, I have a few schools running Facility CMIS, along with Groupcall XPorter. As far as I can tell, since changing the Academic year to 2020/2021, Groupcall is only reading up to Y5 and appears to affect all jobs in Groupcall going to various third parties. ePortal's working fine apparently with Teachers taking registers without issue. Has anyone else observed this issue?

Another solution would be to upgrade 2008 R2 > 2012 R2 or higher, which should resolve the issue.

Could this be an SMB issue possibly?

The SPF record shouldn't be the issue. You need to add the sender address(es) to the Allow list within Exchange Admin > Protection > Spam Filter (top of my head). I'd advise against adding whole domains.

Try restarting Explorer services or the whole VM given you can connect to it via the Hyper-V host.