KK20

then look at the second link for split delivery. A mail enabled "pupil forwarder" contact on the primary exchange server, subdomain accounts for pupils under gmail. Forward from mail enabled contact to gmail subdomain. Leave your MX records intact for delivering to primary domain.

You want DUAL delivery i.e. email delivered to both? So you want to maintain a fully working office 365 mailbox AND a fully working Gsuite mail? This is for pupils only. In that case you want to set up mail forwarding on your primary server and "keep a copy of forwarded messages". If you GSuite and Exchange are the same domain then this wont initially work, you will need a different domain. Be mindful that if people start to send to the alt domain then these will not propagate to the primary domain. If you move all of your pupils from o365 to gmail then you will need a mail enabled contact at least (to forward) remaining on the exchange server. This becomes a split delivery as there will not longer be a mail account on the exchange server for your pupils. In this scenario you will also need mail contacts on gmail to forward back to teachers on your "primary" domain. BAsically "option 2 + option 2" on this https://support.google.com/a/answer/9228551?hl=en#zippy=%2Coption-server-based-forwarding-recommended%2Coption-forward-to-a-test-domain-alias

Receiving emails will break the SPF down as follows. Did the email for "domain.com" originate from 66.33.200.130 or "satisfy egress from spf netblocks.dreamhost.com" or "satisfy egress from spf spf.protection.outlook.com". If it does not then it will fail. Send an email to a client you can check the header even on a fail, look at the headers, look at the SPF fail IP and see where it is coming from, see who owns that IP, that is the SPF you need to get fixed. Perhaps dreamhost.com have a new email server or a different SPF list for "your host cluster" etc. Might be better to change to ~all for the time being if you cannot get a client that shows full fail spf emails (or even ? neutral them)

I think the official way is to pay for premium azure and run a dynamic membership group on the team. We simply run an update powershell script with our "security groups" with our nightly SDS update.

we dont pay for any premium. This is what happens: onprem PW change is synced to o365 cloud no ability for off premises writeback, you basically get an email from the user asking to change their password. which I ignore.

SDS for us. One team created per "class", its automated via powershell scripts for us, data is grabbed from MIS timetable. After than people can create manual ones. The "staffroom" and "tech support" teams are kept up to date with powershell scripts. We dont have azure premium so cannot use dynamic groups.

we did the following: 1) used the MS tool to migrate the WHOLE share from site to sharepoint library. This was after a cleanup phase locally. Dont migrate cruft. 2) set the onsite to "read only" (actually zero quota), that way we could up the quota on portions that didnt work (i.e. we found multimedia was rubbish) 3) used IAMCloud to map drives for staff "as before" so that everything was in the cloud but there are drive letters. 4) used IAMCloud on the old fileserver to reverse sync sharepoint to onsite, this way we have a local backup. The backup is not meant to be spooled up locally but could be in an emergency. We are small enough to get away with veeam community so we dont have fancy cloud backup solutions. This reverse sync works well enough for us. 5) map home drive via IAMcloud to onedrive and set quotas to zero on local documents. Advise staff to start saving and moving to "home drive". We use IAMcloud as it was more reliable than the built in sync client. It also meant we didnt have to pull the trigger on redirecting "documents" to onedrive, we could maintain an onsite "read only" and offsite simultaneously. IAMCloud SSOs on our domain machine, I ahve not issued the client to non domain machines but it simply uses o365 principal to logon. It was childs play to set up. Issues we have found: FILE LOCKING! This is the most annoying portion of sharepoint. There is no way for an admin to release a lock, if a user opens an online library item in desktop client then a file lock is issued. If that user hibernates their machine then technically the file lock should expire in 10 mins - this doesnt always happen and you end up with file locks that you cannot work around - best you can do is copy/rename/delete. But this is very manual. Multimedia does not play well, we left a huge bulk on our local share with quota enabled. latency. There is definitely a lag between opening and closing. Especially those powerpoints that have never had their images compressed. My god there were some monsters. Best of the rest: We have created a lot of scripts to sort out little foibles. Permissions mainly, updates to team members, SDS updates etc. You will become proficient in powershell and scheduled tasks and a master with System.Management.Automation.PSCredential credential files... Training was needed, people are used to using drive letters, no so much using links to files in emails, sharing access with people, REMOVING ACCESS from shares etc.

I want teachers to be able to access pupil onedrive accounts. I have a script that accomplishes this using a combination of Get-MsolGroupMember for my staff and pupil groups. Then get a list of my sharepoint profiles GetUserProfileByIndex cross referencing them with pupil accounts. I can then loop these with get-SPOUser -Site $SPuserURL -LoginName $ADStaffGroupMember -IsSiteCollectionAdmin $true. This works but is reallllllly slooooooooow for 80 staff against 500 pupils. It is roughly 30 seconds per pupil. Is there a way to do this in "bulk" via CSV? I know you can create sites via CSV but what about updating them? Or is there a better way of doing this?

I managed to fix mine. TLDR run Set-SPOTenantCdnEnabled -CdnType Both -Enable $true Longer version. Firstly I had ZERO errors with my sharepoint diagnostic tool. Everything came up green. A friend of mine in another school was doing the same before christmas. His diagnostic tool came up with an error regarding CDN errors. His primary classic site had some images on it, since he didnt care about his primary site he simply deleted all the bits and pieces off it and tried again, his diagnostic tool was now green. When he ran the siteswap he too got the same error I did regarding "The operation is blocked due to maintenance. Please try again later". He looked up the original CDN error and found that to fix that all you need to do is run Set-SPOTenantCdnEnabled -CdnType Both -Enable $true and wait a few hours. He did, ran the site swap and it worked. so I ran Set-SPOTenantCdnEnabled -CdnType Both -Enable $true waited a few hours and guess what? Mine worked too. As per above suggestion, that didnt work for me, I always used to log into the session before doing any diagnostics. I tried waiting for a while between commands etc. In the end, I think that there WAS the CDN error in the background but due to the fact my classic site was empty, this didnt trigger the diagnostic tool enough to bring up any red error. Because my root site was a classic teams, I couldnt change this to a comms site, I needed to use the site swap tool. Just glad it has all worked. Ironically enough, in all the time it took to fix this everyone has migrated all they need to do into teams. I dont really need our sharepoint front end any more....

The annoying part is that it is only "power automate free" that has 10k+ licenses, the rest are below (apart from "unlimited" A1 free licenses)

I never fixed this. Yes we have over 10,000 licenses. We don't NEED that many, our tenant simply came with that many.

I'll double check, I am using a service account that is added to "site admin" for both sites but not "owner". I will try adding to "owner" and see what happens. edit: same error. I even used set-SPOsite to change the primary admin for both new communication and old root site to be the service account. Service account is now primary admin and owner on both sites. my google-fu has also failed me on that error.

I think I may be the only person on the planet that didnt have a good experience with Salamander. Our multi day timetable didnt play well with Salamader- we couldnt get our school divisions correctly assigned and we didnt have a timely response. In the end we didnt need to go ahead with the paid version after the initial setup. They were quite good about things and (of course) they have been rushed off their feet (our wait time was 7 weeks back in April). In the end I knocked up a quick .NET program to leverage our MIS API (XML response), built CSVs according to MS documentation then leverage a Send-CsvFiles scheduled task. This has worked flawlessly for us. There is a bit of work getting the -useStoredCredentials working and you will need to have information on your MIS API to get your CSVs in the correct format for the Send-CsvFiles

I am trying to move our live sharepoint online site into the empty classic root site using Invoke-SPOSiteSwap. The "sharepoint page diagnostic" plugin yields green for both sites (the "classic root" is a bare bones empty site). The error message I get: Invoke-SPOSiteSwap : The operation is blocked due to maintenance. Please try again later At line:1 char:1 Repair-SPOSite comes back "pass" for the site Ive tried at 4 hour intervals but get the same message. I have no idea how to check for maintenance mode or even if there is one. any ideas?

If the students create a login from the fusion 360 program, this used to create a "personal" edition logon, that was not the same as an education one - I mostly got licensing errors from those students. The students that manually went to https://www.autodesk.com/education and created an account had a 50/50 chance of either A) creating their account without any hiccup or B) needing to supply proof that they were a student AND over the age of 13 (which got fun for the year 8's). I never found a way to "bulk create" student accounts for the year group. This is not apple, google or microsoft where you can SSO to your MIS, Azure, Google Classroom or Apple School manager, you have to get each student to sign up for an account individually. I think they have now stopped multiple logons from one account so no creating [email protected] and laminating the password on the wall. If a student had a "personal" verison with their school email, you need to contact support. Ignore the first response as they wont understand what you mean, demand the issue is escalated. Second line usually sort this out quickly and usually set the student as a student account. This gets fun with 90 students signing up at the start of their first DT lesson. Autodesk are a nightmare of a company.

For our lab, we had a task scheduled batch file run on the local machine. It checked a flag on the server vs version installed, if there was a mismatch then it would run --process update --quiet this has worked for quite some time for us.

or you could set the purge time to be your compliance policy. That way ediscovery will still search the purge folder but end users cannot recover from the purge folder. If you must have a local backup then yes, you need a backup program with access to the APIs. There are a number of people who do this - veeam being one of them. We are running hybrid exchange with no plans to move offsite at the moment although we will eventually.

I am waiting for the licence to activate, our reseller is being a little slow. We only had our education account verified within the last few days so the learning curve has been in effect; No radius server -yet- but our proxy supports radius (currently AD with NTLM fallback for ancient devices), so thats now on my todo list. Full AD sync with passwords, OU/group/user sync are already workingetc - I do not want to hijack this thread but the domain query was relevant I thought.

Caffrey, are you saying that you can enrol a chromebook using an education upgrade license and (via whatever policy you set in admin console for that device/OU) lock the domain on the device? For example, at the chromebook logon you would type and this would be interpreted as [email protected]? Does this "automatic domain" propagate to anything else on the system? Proxy authentication for example? I am currently evaluating a chromebook but DO NOT have the upgrade license, hence all my policies are user ones not device (as I cannot enrol the device). I think I need the upgrade licence to admin them effectively.

the main issue with teams is that private chat from student to teacher is not possible whilst blocking student to student. I know this "feature" is in preview but that is almost a deal breaker. Meetings that dont expire for 30 days (or is it 60?) is also iffy. I would love to start weaning people off zoom. I'll probably simply block it from september and pretend only "microsoft zoom" is available.

GSuite education, Azure "free" sync'd with onsite AD plus ADFS. GSuite provisioned via Azure (users updating fine). So far I have NOT enabled GSPS on our domain controllers - that is to come. So, I have followed both MS and google SSO via 3rd party. It works (of a fashion). Using a chromebook, I get three prompts to log in - the initial google prompt ([email protected]), this redirects to MS page with our usual ADFS background (the email address portion is blank so needs to be filled in again - there is no password box on this page, only a request for an email address), then a third simple popup credential box (which is also blank). I obviously missed something or put an incorrect setting/URL as im sure you dont need to put your email address in three times (plus the password right at the end) to log onto a chromebook. ideas?

A follow up. School approved, Sync happened without issue. SSO works and whilst I dont have an education upgrade license to enrol my test chromebook, I can at least log in and the "per user" settings I had put in are working now (filter root cert, specific wifi etc).

It seems that this is because our license is still a trial. This has limited our user count. I simply have to wait until google approves the school.

I am in the process of provisioning G Suite Education. I have created our GSuite education tenant with our domain vanity name. This domain is verified and all good to go. Since we run onsite AD with ADFS and sync to Azure (free A plan) I thought I would use GCDS first. Downloaded the app, set it up and away it went - all the users, groups and OU that I specified int he search and filters worked. Saved the XML, closed and reopened to make sure the token was still "authorised". Removed all the users (except the admins), removed groups and OU so I could test again. Moved onto using the "sync-cmd" command with a view to automating the process. gave sync-cmd -a -c and away it went before failing. Logs show that the process gets everything from the domain then attempts to import into GSuite. For every user account I get: [2020-06-16 18:20:31,885+0100] [pool-857-thread-17] [ERROR] [plugin.google.ApiaryRetryPolicy] Retry attempts exhausted for Creating User @.co.uk, with attempt # 0 [2020-06-16 18:20:31,885+0100] [pool-857-thread-17] [ERROR] [plugin.google.ApiaryRetryPolicy] Last encountered exception: com.google.api.client.googleapis.json.GoogleJsonResponseException: 400 Bad Request { "code" : 400, "errors" : [ { "domain" : "global", "message" : "Invalid Input: primary_user_email", "reason" : "invalid" } ], "message" : "Invalid Input: primary_user_email" } the @.co.uk was correct in each case and theoretically the same as when the GCDS updated - this was the log entry for the GCDS: New user 123: "@.co.uk" Org "Staff" Non-address primary key "xxxxxxxxxxxxx" Given name "xxxxxxx" Family name "xxxxxxx" SHA1 password 0 aliases But this wasnt the end of the story. I thought "why not get Azure to do all the lifting for me?" So I went through the MS documentation for linking the GSuite app as a provisioning app. Guess what? Same error from Azure! Failed to create User '@.co.uk' in G Suite; Error: Message: Message: The remote server returned an error: (400) Bad Request. Web Response: { "error": { "errors": [ { "domain": "global", "reason": "invalid", "message": "Invalid Input: primary_user_email" } ], "code": 400, "message": "Invalid Input: primary_user_email" } } The only hint I get from the azure error is the "domain: Global" portion. Surely that should be "my" domain? But I cannot see anywhere this would be set. Finally, I thought "perhaps I have borked things" so I ran the GCDS from config-manager.exe - lo and behold everything provisioned! Im pulling my hair out, how can the GCDS work but the sync_cmd not? Why does Azure give the same error as the sync_cmd?

We used sharepoint migration tool to move our existing shared folders straight to new sharepoint document libraries. Then we use iamcloud mapper to map these libraries back to their original drive letters for the users. Users have been told that this method is running for two years then no more mapped drive (this is more to see what didn't work). We also incremental sync BACK to onpremises for a local copy, this delta is nightly though so work can be lost throughout the day. The local copy is not accessible by users. Documents were sync'd to onedrive using normal GPO forced migrate of user documents. This was done in stages with the big heavy document holders run almost on a 1-1 basis so we knew they had migrated. No pupils have huge documents so they were done in IT lessons (the pupil GPO was set to run for users on gpoloopback in the IT rooms). This mostly worked. We don't use a home drive, just "documents" and "desktop". So we also scripted people to have a H: drive mapped to their old mydocuments folder, users could copy from H: to "documents" (now using onedrive). We did this just after Christmas, talk about good timing.