sparkeh

Summer 2016

Thanks!

... ... Oh. My. God. Thanks *shiver* - - - Updated - - - Thanks!

Thanks much appreciated

Our school is finalist for an Early Years Winter Display Competition and the winner will be chosen by the highest number of likes on Facebook. Our entry is here: https://www.facebook.com/earlyyearsresources.co.uk/photos/a.943334222408209.1073741827.345559615519009/943338769074421/?type=3&theater If you like it please vote for us, the kids worked really hard on it and it would be great if we won Thanks!

Awesome! Thanks I'll give this a try

Yep, its all in the blog But yeah it was extending the schema but also monkeying around with Azure AD Connect and the Rules Editor to actually get the damn variable sent to Azure. Extending the schema after installing AADC is a major PITA

Just an update to this. I ended up deciding to split my security groups and email distribution lists apart. Though I ran into a problem when trying to alter the setting between letting anyone email the group or internal users only. As I am syncing my AD with Azure I needed to alter an AD variable locally, but that variable did not exist in our AD. Argggh! Solved, and here is the blog post, hope it helps someone: http://www.edugeek.net/blogs/sparkeh/2257-365-azure-ad-connect-distribution-groups-internal-external-senders.html Working out the solution to this actually made me learn a lot about how the whole thing works which was good really

If, like me, you are setting up email with Office 365, you may have stumbled on a little problem with distribution lists. The problem runs like this: You are syncing your on-site Active Directory with Azure AD Connect After syncing your email distribution lists set up in your on-site AD you want to change whether internal users only, or anyone can send mail to the list. You try to alter the setting in 365 but it throws an error saying that as you are syncing your AD it needs to be set in AD by altering the ‘msExchRequireAuthToSendTo’ AD attribute of the Group You find that this attribute does not exist in your AD so you can’t alter it. Dammit! This issue occurred because I was syncing an AD that had not been extended for Exchange with Exchange Online, which uses the ‘msExchRequireAuthToSendTo’ attribute to determine whether internal/external senders can send email to the group. Unfortunately, it appears that information on this issue was scarce and I had to piece together the solution from many different blog posts from people with different issues. Here beginth the solution: Step 1 – Extend your AD for Exchange. So the first thing we need to do is to extend AD for Exchange. This gives us more control of Exchange Online by adding new AD attributes to send off to 365. You can do this with a trial version of Exchange such as the one found here: Download Microsoft Exchange Server 2010 from Official Microsoft Download Center (this is Exchange 2010, I did try 2016 but ran into a strange error when extending the schema, 2010 worked fine though). Extract the downloaded files and, using an account with ‘Enterprise Admin’ and ‘Schema Admin’ permissions, run ‘setup /PrepareSchema’ and wait for it to complete. Hurrah! You should now be able to set the ‘msExchRequireAuthToSendTo’ AD attribute for your distribution group, sync your AD with Azure and find that the option has altered in 365 right? Right? Wrong! Step 2 – Update Azure AD Connect for the updated schema Why doesn’t it work? Unfortunately, when you install Azure AD Connect it picks up the current schema and that’s what it will run with, even if the schema is updated later. Of course if I knew what I knew now I would have extended the schema before I installed Azure AD Connect which would have made everything a lot more simple. But hey, when is IT simple right? The good news is that Azure AD Connect allows you to refresh schema. Hurrah! Load up the Sync Manager, click on the ‘Connectors’ tabs Highlight your local domain, click ‘Refresh Schema’ in the right hand window Puzzle as you are asked you for a password for an account that was automatically generated during the Azure AD Connect installation. Oh… you say, I have no idea what that is. However, it appears that resetting that password has no major effects (the account is only used to access AD for AADC). So go ahead and reset the password. Now you can refresh the schema Hurrah! You should now be able to set the ‘msExchRequireAuthToSendTo’ AD attribute for your distribution group, sync your AD with Azure and find that the option has altered in 365 right? Right? Wrong! Step 3 – Update the AD attributes to be synced Why doesn’t it work? Well, you may have added the new Exchange AD attributes to AADC but it is not set to retrieve them from AD yet. So now we need to tell Sync Manager to do this Load up the Sync Manager, click on the ‘Connectors’ tabs Highlight your local domain, click ‘properties’ in the right hand window Click ‘Select Attributes’ Scroll through and tick ‘msExchRequireAuthToSendTo’ Click ok Hurrah! You should now be able to set the ‘msExchRequireAuthToSendTo’ AD attribute for your distribution group, sync your AD with Azure and find that the option has altered in 365 right? Right? Wrong! Step 3 – Update the AADC sync rules Why doesn’t it work? Ok so this one took a bit of puzzling, a lot of Googling and a bit of playing around. When you intall AADC you get a tool called ‘Synchronization Rules Editor’ which specifies exactly what is retrieved from your local AD (Inbound rules) and sent to Azure (Outbound rules). At this point, let me state that I don’t really understand why you have to tell Sync Manager what to retrieve and send and the same for the Rules Editor as well, but you do. Though I would appreciate someone explaining that to me? So, here it’s a good idea to clone and disable an existing rule and edit the copy (in case you make a major booboo and want to go back to the previous state). For each rule specified below you need to add the following information to the ‘Transformations’ section: · FlowType = Direct · Target Attribute = msExchRequireAuthToSendTo · Source = msExchRequireAuthToSendTo Inbound rules to alter: ‘In from AD – Group Join’ ‘In from AD – Group Common’ Outbound rules to alter: Out to AAD – Group Identity Out to ADD – Group Dynamics CRM Out to AAD – Group Intune Out to AAD – Group LyncOnline Out to AAD – Group SharePointOnline Out to AAD – Group Azure RMS Hurrah! You should now be able to set the ‘msExchRequireAuthToSendTo’ AD attribute for your distribution group, sync your AD with Azure and find that the option has altered in 365 right? Right? RIGHT! It should now work. J

Anything but the glasses. Anything.

Oh yeah River Song is back, thought we'd seen the back of her :rolls eyes:

I loved this episode, one of my favourites ever actually. Although, going against general opinion , I liked Clara, it was good to see The Doctor on his own figuring things out. Can't wait for the final episode

Thanks! Those Security groups are for email distribution only so hopefully that won't be an issue. Gah!

So, migrating from GAFE to 365 and need a pointer. With GAFE I setup Security Groups in AD which synced and created groups which could received and distribute email to members of the group. After syncing AD with 365 I have all the same Security Groups which appear to the same thing, so that mail to the group address will be distributed to the members. However, 365 has 2 types of groups, Security and Distribution. From what I've read it seems that I should be using a distribution group if I'm just using it distribute email. But as I have everything setup in AD, and want to use AD to manage everything (in the way you have to use AD to manage user details if you are syncing) then I would like to carry on using the Security groups. Are there any implications of using security groups rather than distribution groups?

So in summary they have overturned a law which will bring them no benefit and not pursue anyone breaking the law they objected to. Not to mention costing everyone a lot of time and money in the process. What the hell is wrong with the music industry?

Yes, I think that you are right. I think that's where I am headed, much less hassle than trying to remove them before imaging.

Its not the same as Pro. Its has some good extra features: https://www.microsoft.com/en-gb/WindowsForBusiness/Compare But yes its the same as Enterprise, though I believe that future development will bring different features than Enterprise.

Thanks! I had been meaning to update this with Windows 7 support but you have saved me a job

Mind = blown

Nope, the Governors have employed you

It works on El Capitan!

Nope, waiting like you

For a long time we have used WPAD to simplify teachers moving their laptops between home and school and its worked very well. Laptops have the 'automatically detect settings' box ticked in Internet Settings. The location of the wpad file is distributed by both DHCP and DNS. However, after implementing DirectAccess its became apparent that when machines were connecting at home, they would pick up the WPAD settings and all Internet traffic was routed through our gateway/filter/firewall (which we didn't want it to do). The wpad even had an IP check in it which I thought would make the clients use a direct connection. I believe that this is because the DirectAccess remote clients would find the wpad entry in DNS and use its internal IP, not its local IP, so according to the wpad function the machine was 'on network' with an internal IP so it tells the browser to route traffic through the on-site proxy. A simple fix for this was to only publish the wpad location via DHCP. All major browsers now support the DHCP method (unlike a few years ago). Therefore when a DA client connects, it checks DHCP for the location (using its local DHCP server, which fails), then checks DNS (which fails) so uses a direct connection.

Yeah we have a check in our wpad file for the host IP, however, it appears this didn't help. I think its because with DirectAccess your remote client will actually present an internal IP, not your local IP, so according to the wpad function you are 'on network' with an internal IP so it tells the browser to route traffic through the on-site proxy. However, with wpad the client checks DHCP, then DNS for the location of the wpad file, so the remote client won't get a wpad location from the local DHCP and (now I've removed the entry) won't get it from DNS. When the laptops come back on-site they will get the wpad location from DHCP

Yep distributing WPAD settings via DHCP only does the trick Hope this helps someone.