Everybody who’s tried to get Office 365 licenses knows tht it’s not a straight forward as it should be, and getting a list of license holders for a certain SKU may not be simple. The Powershell snippet below let’s you list the license holders for a specific SKU, just modify the last part (currently “*visio*”) to match the product you’re looking for.
Get-MsolUser -all | select displayname,userprincipalname,objectid -ExpandProperty licenses | where accountskuid -Like "*visio*"
To list the SKU’s available in your enterprise agreement, use the command:
My task was to eliminate direct license assignments and start using on Group based licensing in O365. By adding the current license holders to a group, I could remove the direct assignments and ease administration and reporting going forward.
On May 25th, the new EU rules regarding personal information takes affect. General Data Protection Regulation, or GDPR is a set of rules and regulations which standardizes the somewhat confusing national rules which all EU countries have regarding storing, managing and securing personal data.
GDPR is meant to transfer ownership of information back to the user, but it’s also in many ways a simplification of the flux of rules which has been created since the inception of the public internet, and the rise of social media.
As an IT admin today, perhaps the most important thing is to know where your data is stored. It’s easy to start consuming a new cloud service without concerning yourself with where the data is stored, or how it’s secured. GDPR places a responsibility on the employer to ensure that personal data is stored securely and managed responsibly, regardless of where it’s being stored.
GDPR is an extra-territorial regulation. That means that as a non-EU company with employees in any EU membership countries, GDPR governs how personal information is managed, even if it’s stored outside the EU. The fine for breaking GDPR regulations can be as high as €20.000.000,- or 4% of global revenue, whichever is higher. It’s probably cheaper to stay compliant!
When I set up a new application, or subscribe to a cloud service on behalf of my company, I’ve started going through a checklist which is a follows:
- Where is the data stored?
- Is personal data stored?
- Is it encrypted
- Does personal data have a different permission set than content?
- Who in my company has access to personal data?
- User accounts
- Access control lists
- Who outside my company has access to personal informations?
- Is the application/service owner an EU citizen? (if not, brief on GDPR)
- How is data transferred?
- Endpoint to endpoint encryption
My employer is currently working on ramping up personal data compliance for our European employees. It’s as much an HR job as it is technical. HR depends on IT to stay compliant, and IT depends on HR to create the policies.
Is your organization ready for GDPR?
When backing up Active Directory in your local data center, you usually have control of everything from power and cooling, through networking, to physical machines and hypervisors. This also gives you control of the terminal for your virtual machines. In the Azure cloud however, when installing an IaaS VM, this VM is unavailable during reboot. No console, no terminal, no nothing; until the VM starts responding to services defined by the ports you’ve opened through your endpoints, you’re in limbo.
This isn’t usually a problem, but when doing an Active Directory restore, authoritative or otherwise, console access us often used to force the computer into Directory Services restore mode.
Let me take you through an AD restore in Azure. First of all, here’s my status quo:
I’ve got an OU named BackuptestOU, which I’m deleting
Now for the restore:
- Open System Configuration (Windows key, type System Configuration)
- Here’s how it differs from a typical AD restore. Go to the tab Boot and make the following selections
- Press OK and select Restart
- Log on with your Domain Services Restore Mode username and password
- Before starting the Restore, revert boot options. Open system configuration again, and set the options as below to avoid rebooting into Directory Services restore mode after the restore.
- Open Windows Server Backup and press “Recover”
- Choose the correct location for your backup (in my case local)
- Select the point in time you’d like to restore to
- Select “Original Location” and tick of the checkbox “Perform an Authoritative Restore of Active Directory files
- Read this warning and confirm this warning by pressing ok
- Press Recover. I like to have the server reboot automatically, but if you’d like to retain control of the reboot, leave it unticked
- Select Yes to confirm starting the recovery
- Wait for the recovery process to complete
- And last, I demonstrate the AD restore is successful by showing you the OU I deleted. My backup was taken before I moved the last user, which is why there is only one user present.
So I hope this gives you some input on how to manage Active Directory in the Azure cloud. Please feel free to comment any question below.