Tag: directory

  • Cleaning up Office365 Groups Mess

    Cleaning up Office365 Groups Mess

    Office 365 Groups are a shared workspace for email, conversations, files, and events where group members can collectively get stuff done. It compliments the introduction of Microsoft Teams. The main thing to keep in mind is that this feature is still evolving.

    Why is it important to control Office 365 Group creation?

    This feature is enabled by default. So its better to put restrictions in place or later clean up sites, groups, permissions set by organization users.

    Which Group?

    SharePoint frequently reuses terms, which often makes conversations and forum posts a lot of fun. There’s at least three “Groups” in Office 365:

    • Active Directory Groups: Groups at the AD level. Outside of SharePoint. Useable across all site collections, and other applications. A “Sales Managers” AD group can be created once, updated in one place and used across all site collections in the tenant.
    • SharePoint Groups: Collections of users (people) and AD groups. Scoped to a single site collection. A “Sales Managers” SharePoint group would need to be created in each of the site collections and all updates repeated across all of the site collections.
    • Office 365 Groups: A new collaboration option! A combination of a mailbox and a site collection. Not a group useable for managing access to SharePoint sites.

    Office 365 Groups

    Office 365 Groups are a combination of an Exchange email account with the group’s name that is used to store conversations, and a “OneDrive – like” site collection to store files.

    A collection of Office 365 Groups facts:

    • Internally, to distinguish traditional groups from the new Office 365 Groups, Groups are called “Unified Groups”. Externally they should be called “Office 365 Groups”, not “SharePoint Groups”.
    • Creating a Group creates an AD Distribution group, an email address and a “hidden” SharePoint Site Collection. The site collection is not visible in the tenant admin pages. The AD group is not manageable from Azure AD, only from the tenant admin Groups pages. (You can see members in Azure AD, but cannot edit them.)
    • Groups can be created from:
      • Outlook (OWA).
      • A user’s OneDrive.
      • The “GROUPS” page in the tenant Admin site. Here you can create both “Office 365 Groups” and “security groups”.
    • Conversations are stored in Exchange inboxes and files are stored in SharePoint Site Collections.
    • Groups are defined and managed in Azure AD. (Which explains why the PowerShell cmdlets for Groups are not in the SharePoint Online cmdlet library.)
    • Each user may create up to 250 Groups and can be a member of up to 1,024 Groups. There’s no limit for number of Groups per tenant.
    • Emails can be sent in the name of the group by members. (Requires a PowerShell based change.)
    • Groups will not be deleted if the Group’s owner is deleted.
    • Groups use a OneDrive for Business site under the covers. (Template: GROUP#0)
    • URL for the files site collection looks like a normal team site instead of a OneDrive site:  https://yourdomain/sites/groupsitename
    • If there is a URL conflict, a number is appended to the name: https://yourdomain/sites/groupsitename51
    • URL for the mailbox is “guessable”: https://outlook.office365.com/owa/#path=/group/yourGroupName@yourDomain.onmicrosoft.com/people
    • Groups site collections are not (currently) displayed in the admin Site Collections page. You may discover their existence when you create a new site collection that has the same name as a group site. “The site collection already exists. Please enter a different address.”
    • PowerShell:
      • Get-SPOSite does not return Groups site collections, but you can access a Groups site by URL.
      • Get-SPOUser does not return users for Groups sites.
    • Groups file storage is counted against the tenant quota. It’s not considered to be a personal OneDrive. There is no “user” for the Group OneDrive. The mailbox can store up to 50GB of messages, posts and calendar entries. The SharePoint Site Collection has a max of 1TB.
    • Search: There is a search box, but it opens the Search Center in a new window/tab and searches all of SharePoint, not just the Groups file site.
    • The document library in the Group site is very much like a OneDrive for Business library. No ribbon, no custom columns, no metadata and no Content Types. The Groups library is very limited:
      • Only one library, and it’s not customizable.
      • Can’t check out/in. (I saw this listed as a feature, but it’s not in my tenants.)
      • Versioning is enabled (Major only)
      • Cannot add/delete columns (i.e. use any custom metadata that might be useful to search or eDiscovery.)
      • Cannot use workflows.
      • Cannot audit security from the browser.
      • No branding. Cannot be opened by SharePoint Designer.
    • The Site Collection is VERY limited.
      • Almost all of the links for site or list maintenance are redirected to the home page.
      • There is no Settings page.
      • There is no Site Permissions page, so there’s no Site Permissions page or 2nd tier recycle bin.
      • You cannot create new lists or libraries.
    • Library Sync: The Sync button works with the new OneDrive for Business sync client. So, keep in mind that group members of easily offline all of the content.
    • Recycle Bin:
      • There is a recycle bin, but you can only access the user level.
      • If you share a file with a non-member with “Edit”, they can delete the file, but get “Sorry, you don’t have access to this page” when they click the Recycle Bin link.
      • There is no Site Collection recycle bin page available. The Groups “owner” can’t recover files deleted by members.
    • Can be administered and reported on from PowerShell as part of the Exchange Online cmdlets.
      https://technet.microsoft.com/en-us/library/jj200780(v=exchg.160).aspx
      cmdlets: Get/Set/New/Remove-UnifedGroup and Get/Add/Remove-UnifiedGroupLinks
      https://support.office.com/en-us/article/Use-PowerShell-to-manage-Office-365-Groups-aeb669aa-1770-4537-9de2-a82ac11b0540
    • Groups can be disabled for all users. (PowerShell)
    • Groups can be disabled for a subset of users. (Requires PowerShell.)
    • Security:
      • New groups default to “Public”. Everyone has access. You must remember to choose Private when you create the group.
      • I can’t find a place to change Public/Private status after the group has been created.
      • The names of groups are not private. They will be seen in “Send to”, “Share” and other places where user names can be seen. All groups, public and private, are listed in the “Browse Groups” screens. (Train your users not to use group names that reveal confidential data. You know, names like “IT Layoff Planning Group”. 🙂 )
      • Files can be shared with the “group”. They will be listed in the “Shared with us” tab.
      • Files that are shared with the “group” will be visible to all users even for Private groups! (I think this is a bug!) (The user must know the URL to the Files site.)
      • Files can be “reshared”. Sam has a site named “My Private Group”, which is Private, He shares a file with Robert (with Edit or View). Robert can only see that one file in the group site. Robert shares with Susan. Susan can then share with………
      • Users who guess the URL to the file site can see the site, but no files, or only files shared with them. They can see the list of “members” and who the owner is.

    Groups vs. Team Sites

    Groups Team Sites
    Can add lists/libraries No Yes
    Can add pages No Yes
    Can add columns/metadata No Yes
    Can use Content Types No Yes
    Can hide membership No Yes
    Can brand No Yes
    Can be fully managed with PowerShell No Yes

    Cleaning up the mess

    So since this feature is enabled by default. Users in your organization may have already started creating groups and hidden SharePoint site.

    So first we need to disable this option right away.

    Prerequisites:

    Check your Company-level configuration settings

    Now need to check your company-wide configuration settings through the Get-MsolCompanyInfo Windows PowerShell cmdlet. This cmdlet will display your current company-wide configuration settings that affect all users. You specifically need to verify that the UserPermissionToCreateGroupsEnabled parameter is set to False.

    To check your Company-level configuration settings

    You will first need to connect to your Office 365 service. In the Windows Azure Active Directory Module for Windows PowerShell, type and enter the following:

    Connect-MsolService

    In the Sign in to your Account screen, enter your credentials to connect you to your service, and click Sign in.

    You will be returned to a prompt in the Windows Azure Active Directory Module.

    You will need to display your company-wide configuration settings. To do this, type and enter:

    Get-MsolCompanyInformation

    This will display a listing of the current configuration settings that apply to all users in your company.

    As you can see the value for the UsersPermissiontoCreateGroupsEnabled setting is True. We need to change this to False.

    To change the UsersPermissionToCreateGroupsEnabled setting value

    You will first need to use the Set-MsolCompanySettings cmdlet to change the UsersPermissionToCreateGroupsEnabled parameter to False. In the Windows Azure Active Directory Module for Windows PowerShell, type and enter the following:

    Set-MsolCompanySettings - UsersPermissionToCreateGroupsEnabled $False
    

    You will be returned to a prompt in the Windows Azure Active Directory Module.

    After changing the setting, you then need to run the Get-MsolCompanyInfo cmdlet to verify that the value has changed to True.

    Get-MsolCompanyInfo

    After running the cmdlet, check the displayed information to verify that the UsersPermissionToCreateGroupsEnabled setting value has changed to False.

    Identifying the site collections in PowerShell

    Connect to SharePoint

    #Connecting to SharePoint
    
    #User account with Global Admin Permissions
    $adminUPN="[email protected]"
    
    #Organization Name (myorganizationinc.onmicrosoft.com)
    $orgName="myorganizationinc"
    
    #Prompting and using the password
    $userCredential = Get-Credential -UserName $adminUPN -Message "Type the password."
    
    #Making the Connection
    Connect-SPOService -Url https://$orgName-admin.sharepoint.com -Credential $userCredential

    Get a list of Site Collections

    Get-SPOSite -Detailed | Format-Table -AutoSize

    More than likely the Group SharePoint Site is restricted to the user that may have created it. You may get this error when trying to remove it:

    To remove it you need to take ownership as the CollectionOwner

    Set-SPOUser -Site http://myorganizationinc.sharepoint.com/sites/<YourGroupsSite> -LoginName [email protected] -IsSiteCollectionOwner $true

    Now if you want to do this for all the site collections:

    $Sites = Get-SPOSite
    ForEach ($Site in $Sites)
    {
    Set-SPOUser -Site $site -LoginName [email protected] -IsSiteCollectionOwner $true
    }

    Once this is applied the admin will be able to remove the hidden Sharepoint collection. Remove the site collections that are no longer needed.

    Remove-SPOSite -Identity https://myorganizationinc.sharepoint.com/sites/<YourGroupsSite> -NoWait

    Deleting the Groups

    Now to delete the groups that the users created. Head over to the Office365 Admin Portal.

    Click the “Office 365 group” from the selection to show all groups (These should be all cloud based)

    Once the groups are displayed remove them as necessary.

    Groups are no longer in your environment.

    Planning for the future: Migration of Distribution Groups to Groups

    If you are in Hybrid mode you cannot user Groups in a clean fashion. It will get messy. Sooner or later you will need to plan for migration of your distribution groups to Groups. Know your current limitations and hold.

    Migrate distribution lists to Office 365 Groups – Admin help

    Distribution list eligibility for migration

    The following table lists which distribution lists are eligible or not eligible for migration

    Property Eligibility
    On-premise managed distribution list. Not eligible
    Nested distribution lists. Distribution list either has child groups or is a member of another group. Not eligible
    Moderated distribution list Not eligible
    Distribution lists with send on behalf settings Not eligible
    Distribution lists hidden from address lists Not eligible
    Distribution lists with member RecipientTypeDetails other than UserMailbox, SharedMailbox, TeamMailbox, MailUser Not eligible
    Distribution lists with member join or depart restriction as Closed Eligible. Converted to a private Office 365 Group.
    Distribution lists with custom delivery status notifications. ReportToManager = true, ReportToOriginator = false ReportToManager = false, ReportToOriginator = false Eligible. Office 365 groups don’t understand these properties, and delivery status notifications are always sent to the person that sent the email.
  • Remove disabled users from Distribution Lists & Security Groups in Active Directory

    One of my clients had several disabled users showing up in distribution lists and security groups and this was creating unnecessary noise in email, alerts, etc. I highly encourage all administrators to keep their AD neat and tidy.

    The following PowerShell script searches for disabled users in Groups and Distribution Groups and removes them:

    # This script removes all disabled users from all security and distribution groups in the specified "searchOU"
    
    Import-Module ActiveDirectory
    
    $searchOU = "OU=Groups,DC=domain,DC=local"
    
    $adgroup = Get-ADGroup -Filter 'GroupCategory -eq "Security" -or GroupCategory -eq "Distribution"' -SearchBase $searchOU
    $adgroup | ForEach-Object{ $group = $_
    	Get-ADGroupMember -Identity $group -Recursive | %{Get-ADUser -Identity $_.distinguishedName -Properties Enabled | ?{$_.Enabled -eq $false}} | ForEach-Object{ $user = $_
    		$uname = $user.Name
    		$gname = $group.Name
    		Write-Host "Removing $uname from $gname" -Foreground Yellow
    		Remove-ADGroupMember -Identity $group -Member $user -Confirm:$false
    	}
    }

    Hope this helps!

  • Migrate Office365 Photos to AD

    Many of my customers have Office365 and have been using Skype for Business for sometime now. It is likely that your organization users have uploaded their profile picture. Now only if there was a way to sync those pictures back to your AD – so it looks neat & nice. There is a way!

    #MigrateOffice365PhotosToAD.ps1
    
    function Get-Office365Photo($EmailAddress,$Credential) {
        $wc = New-Object System.Net.WebClient
        $wc.credentials = $Credential
        # Build the URL that'll return the jpeg of the user's photo
        $url = "https://outlook.office365.com/ews/exchange.asmx/s/GetUserPhoto?email=$EmailAddress&size=HR96x96"
        # Build a path to export it to (.\[email protected])
        $outPath = "$pwd\$EmailAddress.jpg"
        try { 
            # Download the image and save it to the current directory
            $wc.DownloadFile($url,$outPath)
            return $outPath
        } catch { throw $_ }
    }
    
    function Upload-ADPhoto($Username,$FilePath) {
        # Import the photo into a variable as a byte array
        $photo = [byte[]](Get-Content $FilePath -Encoding byte)
        # Replace the current value of thumbnailPhoto with the byte array from above
        Set-ADUser $Username -Replace @{ThumbnailPhoto=$photo}
    }
    
    # Get the credential to allow us to download the images
    $Cred = Get-Credential -Message "Please enter your Office 365 Credentials"
    
    # Get every mail-enabled AD user
    $users = Get-ADUser -ldapfilter '(mail=*)' -properties mail
    
    # For each of the mail-enabled users...
    foreach ($user in $users) {
        try {
            # Download the photo
            $photoPath = Get-Office365Photo -EmailAddress $user.mail -Credential $Cred
            # Upload the photo
            Upload-ADPhoto -Username $user -FilePath $photoPath
        } catch {
            Write-Warning "Unable to update image for $($user.mail)"
        }
    }

    Source

  • Active Directory: Changing passwords for users in bulk using a .csv file

    Many accounts in your AD might need a password change. What if you want to do this in bulk ?

    First, we need to the userlist. Depending on your requirements we need to get a list of users (specifically samaccountname). For random password generation I recommend using http://manytools.org/network/password-generator/ as it can generate up 1000 for free.

    Here is what my UserList.csv look like:

    sAMAccountName,Password
    test1,gqLfZub$OtO#dBg
    test2,6eXq78gTyx$YjmM
    test3,ZNgl!KdYo7U6yzR
    test4,voiIs!TISw!Wcyc
    test5,W7ZBTAe7CWcFzyn
    test6,BykgCY5b*NGFO5!
    test7,3ApLlchwgRQwf1P
    test8,9jZvvR2$wDggf3M
    test9,*QCDjcgnNLkBDP1
    test10,sZpvUnvjJxAE9HE
    test11,$C8TX!tcS3d#MjK
    test12,Pzw*aH6zjpOx8Wj
    test13,XmfIPiIz82!!X77
    test14,ri!!hQX!w!FSZuI
    test15,S0Gzf6fEUsG!4Ib
    test16,Kj8s!vy94S!ozLJ
    test17,PzFzjP7obALeuWa
    test18,Ri5V2laxxck6Rgg
    test19,Rw8KcX*FoMT#gr1
    test20,QDndAgzdYo5CYX!

    Make sure you do the following on a domain controller or connecting to your domain controller via PS-remote with elevated permissions.

    Run this in PowerShell (Open PowerShell in Admin Mode)

    PowerShell:

    Import-Module Active Directory
    $Resetpassword = Import-Csv "c:\_Scripts\UserList.csv"
    
    foreach ($Account in $Resetpassword) {
        $Account.sAMAccountName
        $Account.Password
            Set-ADAccountPassword -Identity $Account.sAMAccountName -NewPassword (ConvertTo-SecureString $Account.Password -AsPlainText -force) -Reset
    }

    [su_note note_color=”#fafae8″]-Reset
    Specifies to reset the password on an account. (User is not prompted to change password).
    To use this parameter, you must set the -NewPassword parameter.
    You do not need to specify the -OldPassword parameter.
    [/su_note]

  • DFS Namespace service could not initialize cross forest trust information

    After you install Active Directory on Windows Server 2008 R2, you may start seeing the following error message after the server boots:

    The DFS Namespace service could not initialize cross forest trust information on this domain controller, but it will periodically retry the operation. The return code is in the record data.

    This occurs because the DFS Namespace service attempts to access Active Directory before it has completely initialized.
    To resolve this issue, we simply have to force the DFS Namespace service to start after the Active Directory service has initialized. We can do this by setting the DFS Namespace service to depend on the Active Directory service as well as setting it to a Delayed Startup mode.

    To make those changes, start regedit and make the following changes :

    1. Navigate to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dfs
    2. Modify the DependOnService value and add NTDS to the list.
    3. Create a new DWORD value named DelayedAutostart and set its value to 1.
  • Change the password age in bulk for Active Directory accounts

    Ran into an interesting situation where pretty much all domain accounts did not follow the default password policy and had the option of ‘password never expires’ checked. I needed to fix this immediately without impacting the users and expiring any accounts that may affect the business.

    I needed to adjust the password age for all domain accounts so that they follow the password aging policy. Typically a password age policy is upto 90 days. Powershell to the rescue:

    Import-Module ActiveDirectory
    
    $list= Get-ADUser -SearchBase "DC=yourdomain,DC=local" -Properties samaccountname -Filter *
    foreach ($entry in $list) {
    	$sam = $entry.samaccountname 
     
    	$todouser = Get-ADUser $sam -Properties pwdLastSet -Server yourdomaincontroller.local
         
    	$todouser.pwdLastSet = 0 
    	Set-ADUser -Instance $todouser 
         
    	$todouser.pwdLastSet = -1 
    	Set-ADUser -Instance $todouser 
    }

    So now that all the accounts have a password age of 1 day. Time to uncheck that ‘password never expires’ box. Now for some service and system accounts I wanted them to have password never expires. So now I needed to work with a filtered set.

    I grabbed the accounts I wanted and was able to save them in a .CSV file.

    change.csv contents:

    SamAccountName
    Aespinoza
    ahernandez
    aray

    Now to perform the task on each account:

    import-csv C:\ServerCleanup\change.csv | ForEach-Object {Set-ADUser -Identity $_.SamAccountName -PasswordNeverExpires:$FALSE}
    

    Hope this helps if you run into a similar situation.