Step by Step Directions for Techs
Category Archives: Active Directory
April 30, 2017Posted by on
I keep running into this so I thought I would put it up here.
If you have a customer without on-premise Active Directory and they use Office 365, you can leverage that with Windows 10. It is a bit cumbersome for some things, like adding users to the admin group. Here is a workaround:
- Login as the AzureAD / Office 365 user you want to be a local admin. This introduces that user’s GUID to the system.
- Log out and login as a local admin user.
- Open a command prompt as Administrator and use this command, replacing the username:
net localgroup administrators AzureAD\JohnSmith /add
Regarding the user name: It isn’t the name they login in with. This is the display name all run together. For example, if they are listed as “Bill Jones” in the directory and they login as “bill_jones”, it would be “BillJones”. If they are listed in the directory as “William Jones” (again the display name) but login as “bill_jones”, it would be “WilliamJones”.
October 24, 2013Posted by on
Well, you can’t. Have a great day!
Aside from this being super helpful, I have a workaround for you based on this post from Microsoft (it has a few minor errors) – http://social.technet.microsoft.com/wiki/contents/articles/15905.how-to-use-powershell-to-automatically-assign-licenses-to-your-office-365-users.aspx
This file (rename it to ZIP) has the Powershell files: O365LicenseScripts
This assumes that you have the MS Online Services Sign-In Assistant (you already have this if DirSync is installed) and Microsoft Online Services Module for PowerShell (found here http://g.microsoftonline.com/0BX10EN/423).
How to get it working:
- Unzip the files to C:\O365LicenseScripts (or where you keep your scripts). You can also recreate the scripts from the MSFT post, but there are a few issues with spaces, file names, and it doesn’t set a location for the users before assigning the license.
- Open Powershell
- CD to C:\O365LicenseScripts
- Run .\SetupScript.ps1
- [Office 365 directory sync account – using the onmicrosoft.com address]
- [Password for account]
This is the attribute in AD you are using to identify which users get licenses
Value that the users will have if in AD they are supposed to have the license
The attribute in AD that has the license name, like OFFICESUBSCRIPTION for Office.
- This will create several scripts from the TMP files and some text files.
If you run Get-LicensingInputFromAD.ps1, you will see what the system thinks the users should be and their corresponding licenses.
If you run AssignLicense.ps1, it will assign the licenses based on what the Get-LicensingInputFromAD.ps1 script output was (stored in the queuedLicense folder created during setup).
If you want to schedule it, you can use the Schedule.ps1 script. I won’t go too far into the weeds, but the command is “powershell.exe” (without the quotes) and the arguement is “-file C:\O365LicenseScripts\Schedule.ps1” (without the quotes).
There is one difference in my scripts. You will find 2 lines that are commented out in case you don’t want to set the license type in Active Directory. I often find that most customers only use one license type, so I put in an attribute to say which accounts get the license and then hard set the license in the script (set it in the TMP file otherwise the setup script will delete your work!).
October 23, 2013Posted by on
Who really wants to see all those pesky accounts and groups up in Office 365? Not me (and probably not you if you are reading this). I want to see accounts that I need to give licenses to.
Disclaimer – you can really mess up Office 365. Be careful!
- In Windows Explorer, navigate to “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell7”.
- Double click miisclient.exe to open this window
- Click on “Management Agents” on the toolbar.
- This is where the magic happens. Right click the “Active Directory” agent and choose properties.
- Select “Configure Connector Filter”.
- Select “user” by scrolling down in the right pane to view the filters for this object.
- Add your filters!
These filters are for things you don’t want. As you can see in the image above, I am filtering for users that DO NOT contain “365” in the ExtensionAttribute15 (you can edit that in Active Directory). By using this, I will only get users that have it. Consider it a “negative filter”.
Now, before you work on this too long, let me give you some hints:
- You can’t filter users based on their group membership. It has to be an attribute that is in their user account (think about what you can see in Active Directory).
- You cannot see attributes that you put in by extending the schema, so you can’t filter on those either.
- If you don’t want to sync other objects, like groups, don’t uncheck the object types or delete the joins or anything else like that. It breaks the sync with Office 365. Instead filter all the objects out by choosing something that you know every object has. In this situation, I didn’t want to replicate the groups to O365, so I filtered for every group object that had a GUID:
- If you really mess something up, delete the Azure agent and the AD agent and re-run the DirSync configuration. It will recreate the agents in their vanilla form. If you messed up Office 365, this may or may not fix it.
That should get you going. Good luck!
October 23, 2013Posted by on
If you need DirSync to initiate a directory synchronization immediately, you can perform the following procedure:
- Open Powershell
- Navigate to the Windows Azure Active Directory Sync directory
- cd “C:\Program Files\Windows Azure Active Directory Sync\”
- Launch the config shell
- A new window will open. Type “Start-OnlineCoexistenceSync” (without the quotes)
(if that command gets too long, don’t forget that pressing the TAB key will complete your commands in PowerShell!)
That’s it. I know it isn’t very impressive. Where is the status? How do you know if it worked? I will show you that too!
- In Windows Explorer, navigate to “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell”
- Double click on miisclient.exe to open this window:
This gives you the status of all of your jobs that have ran, including the current one that was initiated from the script!
May 17, 2011Posted by on
A quick and easy way to see which domain controller authenticated you is to run this command from a command prompt:
Quick and easy.