How many users are in my AD group?

Nice simple three liner here. I often want to check how many users are in a particular group, and find it a bit annoying that ADUC doesn’t show this in the Group Properties. So to find out, run this from a Powershell window on a DC:

Import-Module ActiveDirectory
$group = Get-ADGroupMember "group name" -recursive | Select-Object name
$group.count

The second line puts all the members into a variable called $group, and if you didn’t already know, putting .count after any variable will enumerate the objects in that variable ūüôā

Happy days!

Advertisements

Append Description to a list of users

Today I needed to append, not overwrite, the description variable for a list of users. To do this, I created a simple .txt file containing the usernames I wanted to change.

lewish
nicor
maxv
sebastienv
kimir
danielr

I then ran this very simple command which takes the existing Description and adds the phrase “User Enabled 07/06/2016” to the end of the Description.

Get-Content "c:\migration\userstest.txt" | get-aduser -Properties Description | ForEach-Object { Set-ADUser $_ -Description "$($_.Description) User Enabled 07/06/2016" }

Easy peasy lemon squeezy!

Stale Forest / External Trust

Recently I had to remove an External Trust between two domains and replace it with a Forest Trust. Simple work for an Active Directory consultant, you might think, but as with most consultancy work, it’s the simple stuff that catches you out!

After removing the external trust, I validated that it had indeed been removed by checking in Active Directory Domains & Trusts, and also by running netdom query trust. However when trying to create the new Forest Trust, an error message was shown stating that an external trust still existed. More specifically, the error stated:

A trust relationship with the domain you specified already exists

It turned out that, although both the GUI and the netdom commands showed that the trust had been deleted, a stale object still existed. To remove this object, ADSIEdit.msc was used, which is always a risky business! The process for this was:

  1. Open ADSIEdit.msc – If you are running Server 2003, you must install the Windows Server 2003 Support Tools
  2. Connect to the Domain partition
  3. Expand the System container
  4. Find the stale object, the name of this will be of the domain being trusted, and the class is trustedDomain
  5. Delete this trust object

trustedDomain object

This should allow you to create the new trust object.

Azure App Cloud Discovery & PAC Files

Azure App Cloud Discovery is a seriously cool piece of technology. Being able to scan your entire computer estate for cloud SaaS applications in either a targeted, or catch-all manner can really help discover the ‘Shadow IT’ going on in your environment. Nowadays, users not having local admin rights won’t necessarily¬†stop them from using cloud SaaS apps in any way which is going to increase their productivity. Users don’t generally think about the impact of using such applications, and the potential for data leakage.

But, as with lots of Microsoft’s other cloud technologies which are being launched left, right and centre at the moment, the Enterprise isn’t catered for as it might hope. Most Enterprise IT departments¬†leverage some kind of web filtering, or proxying. This may be using transparent proxying, in which case you can count your blessings as Cloud App Discovery will work just fine. If you are explicitly defining a proxy in your internet settings, then you can get around that¬†by adding particular¬†registry keys. However if you are using a PAC file to control access to the internet, then unfortunately Cloud App Discovery will not work for you. This is a shame as it is, in my opinion, the best way to approach web proxying in an Enterprise, but that’s another story. From what I have heard, a feature is in the works which will allow you to configure Cloud App Discovery agents to log their findings to an internal data collector. This data collector can sit on a local server and then upload data to Azure on your behalf, which is¬†a much more elegant solution to the problem of data collection from multiple machines. However as far as I know, this feature is not available yet. I’ll be keeping my ear to the ground and will let you know if this changes.

In the meantime, if you are desperate to get your data collection up and running in the meantime, you could change to explicitly defined proxying, and configure registry settings for your clients as per the following MS article:

https://azure.microsoft.com/en-gb/documentation/articles/active-directory-cloudappdiscovery-registry-settings-for-proxy-services/

Cloud App Discovery is a feature of Azure Active Directory Premium, a toolkit designed to take your Azure Active Directory to new, cloudier heights. Azure AD Premium can be bought standalone, or comes bundled with the Enterprise Mobility Suite. I would highly recommend it to Office 365 customers as it can give you and your users some great new features which can help make your Azure AD the best it can be!

Edit: It looks like PAC file support has been added rather surreptitiously. No announcement was made, and the KB articles haven’t been updated.¬†I happened to check the Change Log today and Release 1.0.10.1 includes an option to tweak your PAC file to support Cloud App Discovery. https://social.technet.microsoft.com/wiki/contents/articles/24616.cloud-app-discovery-agent-changelog.aspx

Alternatively, if you use a PAC file (Proxy Auto Configuration) to manage proxy configuration, please tweak your file to add https://policykeyservice.dc.ad.msft.net/ as an exception URL.

I’m yet to test this myself but it looks promising!

Azure Active Directory Sync – AAD Connect Disaster Recovery and High Availability

I just wanted to write and tell you all about a fantastic new feature built into the AAD Connect tool. It’s name is ‘Staging Mode’ and it has a dual purpose; a) it¬†allows you to have a server which is essentially on standby, and b) it can be used just as it’s name suggests,¬†in a kind of test mode where you can see what is being imported before it all gets sent off to Azure AD.

In real life it would be utilised thus:

Customer A has a functional installation of AAD Sync / AAD Connect which is synchronising objects and attributes between Azure Active Directory and the On Premise Active Directory. They then build an AAD Connect¬†server in their DR datacentre (or wherever they fancy), and during the initial configuration, enable ‘Staging Mode’. Apart from this setting, they configure it just like their existing, live AAD Sync / AAD Connect server. They even leave the scheduled task enabled and running. All of a sudden, DR strikes, and the live AAD Sync / AAD Connect server goes offline forevermore, cast into the computer graveyard in the sky. Rather than restore the server from backup, they simply log into their second AAD Connect server and disable ‘Staging Mode’. This server then starts synchronising with Azure Active Directory in earnest, without having to miss a beat.

What Staging Mode does is very simple. It acts just like a functional AAD Connect installation, except for the fact that it exports nothing to Azure Active Directory or your on premise Active Directory. It also does not perform any password sync or password write-back functions. The metaverse is fully populated and ready to start exporting data, giving you the easiest possible way to have a server on standby. Unfortunately there is no replication between your two synchronisation servers, so any configuration changes need to be replicated manually, but this is another step to making AAD Connect fully HA, which is becoming much more desirable as Azure Active Directory gains traction.

AADConnect Staging Mode

Synchronised User not Provisioned in Lync Online

Today I came across an issue with Lync Online during an implementation of Office 365. We synchronised the user accounts and password hashes using AADSync and applied E3 licenses to a few test users in the IT team. Their testing was successful with the exception of Lync Online, which they could not login to with their synchronised @contoso.com account. The error returned to them was as follows:

Lync couldn't find a Lync Server for contoso.com. There might be an issue with the Domain Name System (DNS) configuration for your domain. Please contact your support team.

Lync Online DNS Error

I tested using my own testuser@contoso.com account and could successfully login to Lync Online internally and externally, which showed me that the DNS records were created correctly. After looking at the firewall logs it appeared that the DNS name lyncdiscoverinternal.contoso.com was being unsuccessfully looked up. This DNS record is used for On Premise Lync installations. I also noted that in the Office 365 Lync Admin centre, the user had not been provisioned.

After quizzing the customer, we discovered that a proof of concept Lync server had been installed a while back and enabled for a few test users in the IT department. This server was not properly decommissioned so AD attributes still existed for these test users. In order to get Lync Online to provision the accounts we had to go into ADSIEdit and clear the following attributes so that they were empty:

msRTCSIP-DeploymentLocator
msRTCSIP-FederationEnabled
msRTCSIP-InternetAccessEnabled
msRTCSIP-Line
msRTCSIP-OptionFlags
msRTCSIP-PrimaryHomeServer
msRTCSIP-PrimaryUserAddress
msRTCSIP-UserEnabled
msRTCSIP-UserPolicies

We then ran a delta sync and hey presto, our user accounts were provisioned in Lync Online and the users could successfully login. The error message we initially given was fairly misleading, but this just shows you how important proper decommissioning is when it comes to essential services like Lync and Exchange.