+ Post New Thread
Page 1 of 2 12 LastLast
Results 1 to 15 of 25
Cloud Services Thread, Office 365 - Not a good start in Technical; Hello all, I've signed up a school to Office 365, registered and confirmed the domain ownership, created users via a ...
  1. #1

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339

    Office 365 - Not a good start

    Hello all,

    I've signed up a school to Office 365, registered and confirmed the domain ownership, created users via a CSV and now under licenses, all I can select are between two A3 plans. We'd like to use the A2 plan.

    I tried the online chat facility/support from Microsoft and they themselves were unclear why A2 does not appear under licenses. Can anyone explain is this normal and how do I get A2 as an option to choose from? Many thanks!

  2. #2
    mwnci's Avatar
    Join Date
    Oct 2006
    Location
    Cornwall
    Posts
    91
    Thank Post
    5
    Thanked 24 Times in 17 Posts
    Rep Power
    20
    You need to 'Purchase' A2 licenses. Go to purchase on the left in the management portal. Add A2 Faculty and Pupil licenses to you cart, and place an order. As an educational establishment, they are priced at £0.00

  3. #3

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339
    I don't see purchases either. I visited here: https://login.microsoftonline.com signed in as admin.

  4. #4

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339
    This is all I see:

    O365.png

  5. #5
    mwnci's Avatar
    Join Date
    Oct 2006
    Location
    Cornwall
    Posts
    91
    Thank Post
    5
    Thanked 24 Times in 17 Posts
    Rep Power
    20
    Is your admin account a global administrator?

  6. Thanks to mwnci from:

    Michael (19th October 2012)

  7. #6

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339
    No idea - but when I re-logged in as the default administrator (before registering the real school domain), it gives me the options I'm looking for.

    I have to say, this really is a design problem. The back end on Live@Edu was much more straight forward. I now have the task of allocating licenses. Why couldn't this have been done from the start with a CSV?

  8. #7

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339
    You were right about the Global Administrator setting Thanks!

  9. #8

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339
    Next question, how can I easily allocate licenses to a group of users?

  10. #9
    jamesbmarshall's Avatar
    Join Date
    Feb 2010
    Location
    Reading, UK
    Posts
    502
    Thank Post
    26
    Thanked 223 Times in 154 Posts
    Rep Power
    84
    Sorry to hear you hit a few bumps along the way to deploying - but glad to see that you've finally been able to purchase the licenses you require. The reason they're not there be default is because we need to go through a process of verifying that you're eligible for the free service (by adding a education domain). Once you've verified a domain, and are logged in using an appropriate account you'll have access to purchase all the free and paid-for SKUs.

    Licensing is handled on a per-user basis. It is possible to select multiple users from the GUI, or you could use Windows PowerShell to assign licences. As an example:


    • Synchronise your tenant with your local AD using DirSync.
    • Populate an attribute, say customattribute1, with some information (i.e. 1 = students, 2 = staff, etc.).
    • Decide that students will get the Exchange Online component of Plan A2, staff will get Exchange Online, and Lync Online, etc.
    • Write a PowerShell script that looks for newly provisioned users, reads the customattribute1 attribute, and then assigns corresponding licence SKUs depending on the value of the attribute.


    Scripting licence assignment is fairly straightforward, and I've written a blog post that should help you get started.

  11. #10

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339
    Thanks James. What I'll do (when I've finished working my way around), is write a few mini guides, as I think Office 365 could do with tweaking slightly so other admins avoid the same traps I have

  12. #11
    jamesbmarshall's Avatar
    Join Date
    Feb 2010
    Location
    Reading, UK
    Posts
    502
    Thank Post
    26
    Thanked 223 Times in 154 Posts
    Rep Power
    84
    Quote Originally Posted by Michael View Post
    Thanks James. What I'll do (when I've finished working my way around), is write a few mini guides
    I'd love to see them if you do.

  13. #12

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339
    Here are my thoughts this afternoon

    Signing up to Office365

    When you first sign up to Office365, it prompts you to create a temporary domain. When you sign up to Live@Edu, you can use your existing domain from the beginning. I think it was better this way, as you just need to update your MX records when you're ready to move.

    Adding Domains + First User

    Once you're signed in as the administrator (using the temporary domain), you can add your real domain. Just like Live@Edu, you're then required to prove ownership (this is fine).

    You then typically (as I did) wish to create an administrator account for my real domain. I did this, however there are a list of administrator roles to choose from. As a suggestion, the first account created should be a Global Administrator by default. Otherwise (like I did), if you choose any other administrator role, the 'Purchasing' of licenses is not possible. This even confused Microsoft Support when I asked the question and it could easily be avoided.

    Users and Licenses

    Creating a CSV file is straight forward and importing users is straight forward too. No where does it suggest however to setup licensing (as a recommendation) before importing users. If you do this the other way around, you'll need to set licensing manually per user. As a result, I was forced to delete my newly imported users and start again.

    Setting up licensing first allows the Office365 import process to also add users into the correct licensing package you have purchased automatically.

    When you've imported your users, there's a small 'log' link. You can open/print this for a list of usernames/passwords. This is useful, but I only clicked on it by chance.

    Improvements to be Made

    When adding your real domain, you should be prompted to create a Global Administrator by default - this is the case with the temporary domain anyway!

    Before adding users (in bulk), the admin should be recommended to evaluate licensing packages first.

    Setting up Security Groups is simple enough, but adding users into groups is a nightmare. You have one huge list. When importing via CSV, you could include an additional 'Group' column. If the group doesn't exist (when imported), then it gets created. What's the solution for this as it stands?

    It still isn't possible to include aliases in the CSV.

    Users are still prompted to confirm their Time Zone at logon. I am aware there's a PowerShell script to get around this, but again, this could be included within a CSV optionally.

    There still isn't a way to automatically allocate Calendars to users. Users still have to accept the calendar.

    I think (just like Active Directory), admins should be able to specify the password policy for Office365, rather than be forced. The requirements are too high in my opinion. It would be useful to have the option to blacklist commonly used passwords for example too.

    Thanks for reading!

  14. #13
    jamesbmarshall's Avatar
    Join Date
    Feb 2010
    Location
    Reading, UK
    Posts
    502
    Thank Post
    26
    Thanked 223 Times in 154 Posts
    Rep Power
    84
    Quote Originally Posted by Michael View Post

    Signing up to Office365

    When you first sign up to Office365, it prompts you to create a temporary domain. When you sign up to Live@Edu, you can use your existing domain from the beginning. I think it was better this way, as you just need to update your MX records when you're ready to move.

    The process for signing up for Live@edu meant that unless you had a domain spare you couldn't really get access to the service, even if you just wanted to evaluate. By doing it this way round with Office 365 it allows customers to evaluate the service for 30 days without needing their own domain name, as well as being able to just get started from day one. The .onmicrosoft.com domain that you get as part of signing up is a requirement, and has no impact on your ability to use any other domain names (in fact, it's very useful when it comes to federating).


    Quote Originally Posted by Michael View Post
    Adding Domains + First User

    Once you're signed in as the administrator (using the temporary domain), you can add your real domain. Just like Live@Edu, you're then required to prove ownership (this is fine).

    You then typically (as I did) wish to create an administrator account for my real domain. I did this, however there are a list of administrator roles to choose from. As a suggestion, the first account created should be a Global Administrator by default. Otherwise (like I did), if you choose any other administrator role, the 'Purchasing' of licenses is not possible. This even confused Microsoft Support when I asked the question and it could easily be avoided.
    You should keep your "super admin" in your .onmicrosoft.com domain as you will always be able to access this even if you chose to federate any other domains that subsequently suffer an outage (i.e. because your local federation server goes down). The administrator roles are there to allow you to devolve power to others, but purchasing licences carries a potential cost which is why it is restricted. Generally speaking, you don't need to adjust your licence count on a daily, or even monthly, basis.

    Quote Originally Posted by Michael View Post
    Users and Licenses

    Creating a CSV file is straight forward and importing users is straight forward too. No where does it suggest however to setup licensing (as a recommendation) before importing users. If you do this the other way around, you'll need to set licensing manually per user. As a result, I was forced to delete my newly imported users and start again.

    Setting up licensing first allows the Office365 import process to also add users into the correct licensing package you have purchased automatically.

    When you've imported your users, there's a small 'log' link. You can open/print this for a list of usernames/passwords. This is useful, but I only clicked on it by chance.
    You can bulk assign licences after you create your users as well - just select multiple users in the portal and you can edit them together. The GUI is just one way to do this - if you're looking for something more easily automated look at DirSync to handle user provisioning, and Windows PowerShell to manage passwords and licences.


    Quote Originally Posted by Michael View Post
    Improvements to be Made

    When adding your real domain, you should be prompted to create a Global Administrator by default - this is the case with the temporary domain anyway!
    You don't need an administrator account for every domain. Your .onmicrosoft.com administrator account will be able to administer users in other namespaces, and as previously mentioned, it's advisable to keep your admin in that namespace.

    Quote Originally Posted by Michael View Post
    Before adding users (in bulk), the admin should be recommended to evaluate licensing packages first.

    Setting up Security Groups is simple enough, but adding users into groups is a nightmare. You have one huge list. When importing via CSV, you could include an additional 'Group' column. If the group doesn't exist (when imported), then it gets created. What's the solution for this as it stands?
    The solution is DirSync. Managing your tenant exclusively using CSV imports is possible, but I strongly recommend DirSync to sync your local AD with Office 365 - this will handle that sort of thing automatically; it also means you have one single place to manage your users: your local AD.

    Quote Originally Posted by Michael View Post
    It still isn't possible to include aliases in the CSV.

    Users are still prompted to confirm their Time Zone at logon. I am aware there's a PowerShell script to get around this, but again, this could be included within a CSV optionally.
    It's possible to write yourself a little PowerShell script to import users, set their password, dictionary language and regional settings, and any other details. The logic being:


    • Import users from CSV
    • For each user imported run a bunch of configuration settings


    Quote Originally Posted by Michael View Post
    There still isn't a way to automatically allocate Calendars to users. Users still have to accept the calendar.

    I think (just like Active Directory), admins should be able to specify the password policy for Office365, rather than be forced. The requirements are too high in my opinion. It would be useful to have the option to blacklist commonly used passwords for example too.
    If you want to dictate your own password strength policies you can deploy AD FS 2.0 or Shibboleth; this moves the authentication to your local AD and users will be required to adhere to whatever local password policy you have in place. Obviously, we strongly recommend that you adopt a strong password policy.

    Thanks for all your points Michael; you've certainly given some great feedback. Hopefully my comments are useful - I accept that there are differences between Live@edu and Office 365 that take some getting used to.

    If you're already on Live@edu have you given any thought to upgrading?

  15. Thanks to jamesbmarshall from:

    Michael (19th October 2012)

  16. #14

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339
    Thanks for the feedback James. At the current time I have no plans to move existing schools from Live@Edu to Office365. Live@Edu has been in place for literally months and plus there are some differences with Office365 I'm still learning (you can probably tell).

    I've decided importing/creating users via the CSV method is better. Many Primary schools I work at would typically have one Domain Controller and do not have the available funds to invest in another server. As you pointed out, if that single Domain Controller goes down then it would create a whole range of problems. For example, if that Domain Controller went down over the weekend, it would also mean users couldn't log into their e-mail from locations outside of school.

    Also, many Local Authorities they have a tendency to do maintenance work during the weekends or school holidays. If internet connectivity to that Domain Controller is lost, again it would stop users accessing e-mail out of hours. This is something I have no control over.

    To be honest, I think the SSO solutions are better suited to larger educational establishments or businesses, rather than Primary schools. It just isn't realistic. I think the majority of schools I've ever been to have relaxed the 2003/2008 Server password requirements. Why you may ask? For the simple fact it's too difficult for young children and I've mentioned this on numerous occasions in the past. This is one reason why I won't move schools from Live@Edu to Office365. The password requirements need to be relaxed.

    The irony here is that with an SSO solution in place, users could have their Office365 password as 'password' if they so wished. By all means, like 2003/2008 Server, let the password requirements be high by default, but still allow schools to reduce the requirements.

  17. #15

    Michael's Avatar
    Join Date
    Dec 2005
    Location
    Birmingham
    Posts
    9,241
    Thank Post
    239
    Thanked 1,567 Times in 1,249 Posts
    Rep Power
    339

    Thumbs up

    Here are some commands that will help Office365 admins:

    Import Office365 cmdlets (both files) here

    Sign in to PowerShell:

    Code:
    import-module MSOnline
    Then enter:

    Code:
    connect-MsolService
    Set passwords for users (bulk):

    Code:
    Get-MSOLUser | Select UserPrincipalName|Export-Csv C:\temp\office365.csv
    Once you've created the office365.csv file, open it and filter out staff e-mail addresses and the admin account. Save the file. Cut and paste staff e-mail addresses into a new file office365staff.csv.

    Command to run for pupils:

    Code:
    Import-Csv c:\temp\office365.csv |%{Set-MsolUserPassword -userPrincipalName $_.UserPrincipalName -NewPassword School123 -ForceChangePassword $false}
    Command to run for staff:

    Code:
    Import-Csv c:\temp\office365staff.csv |%{Set-MsolUserPassword -userPrincipalName $_.UserPrincipalName -NewPassword Teacher123 -ForceChangePassword $true}
    Set passwords to never expire:

    Code:
    Get-MsolUser | Set-MsolUser –PasswordNeverExpires $True
    View password policy for domain:

    Code:
    Get-MsolPasswordPolicy –DomainName domain.sch.uk
    Any ideas how disable Messenger in Office 365? The command for this in Live@Edu was (see below). I found this, but can't get it to work. Any ideas?

    Code:
    Set-OwaMailboxPolicy OwaMailboxPolicy-DefaultMailboxPlan -InstantMessagingEnabled $false

  18. 4 Thanks to Michael:

    GrumbleDook (24th October 2012), jpaterson (26th October 2012), Roberto (25th October 2012), zag (26th October 2012)

SHARE:
+ Post New Thread
Page 1 of 2 12 LastLast

Similar Threads

  1. Not a good start to the year....
    By Gatt in forum Hardware
    Replies: 26
    Last Post: 7th January 2011, 10:56 AM
  2. Not a Good Day :(
    By Gatt in forum General Chat
    Replies: 4
    Last Post: 17th August 2009, 09:43 PM
  3. Printer script not running at start up
    By richard in forum Scripts
    Replies: 11
    Last Post: 29th May 2007, 07:39 PM
  4. AUP Script thats not quite good enough
    By Pear in forum Scripts
    Replies: 8
    Last Post: 28th September 2006, 07:21 AM

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •