Categories
Azure Office 365 PowerShell

Office 365: Managing your users through PowerShell

If you’re like me, then you tend to find yourself wanting to automate as much as possible, or at least be able to work with sets of data in a way that quickly allows you to get to the root of an issue rather than clicking through endless screens of information.

In case you were curious, Office 365 makes use of Azure Active Directory behind the scenes for user managment. As Azure Active Directory is an enterprise resource for identity management for cloud hosted applications, Microsoft has gone to great length to create several interfaces to it. Granted, I could just use a REST call through the Microsoft Graph API to create or delete a user through a POST command, but I can also use PowerShell from a Windows based device.

For user management, our first step is to download the appropriate PowerShell Module.  This can be done simply by installing the module through PowerShell running

install-module -name azuread

This will install the PowerShell module specifically for Azure AD and allow you to manage your users. From there before you can make any changes to your user base you’ll need to authenticate. An easy way to do this is as follows:

$creds = get-credential -credential
connect-azure-ad -credential $creds

From there you can parse your users and make modifications to your hearts desire. Running “Get-AzureADUser” enumerates all user objects.  Load it into an array and work with the users as you wish.

Nevertheless, for more on this topic, check out the Microsoft Support docs over at:

https://docs.microsoft.com/en-us/office365/enterprise/powershell/connect-to-office-365-powershell

https://www.powershellgallery.com/packages/AzureAD/2.0.1.3

Categories
Cloud

Microsoft Azure – PowerShell March 2015 Update

Without much fanfare, the Azure PowerShell commandlets have been updated as of 31 March 2015 to version 0.8.16. More pertaining to the update can be read here:
https://github.com/Azure/azure-powershell/releases/tag/v0.8.16-March2015

If you’ve been watching the Azure Content repo on GitHub you probably noticed a ton of things pertaining to HDInsight being committed. Well, you guessed it, there are a lot of new additions when it comes to Azure HDInsight, specifically on Linux when to provide:
– Support for creating, deleting, listing, and submitting jobs to HDInsight clusters with Linux Operating System.

Additionally there are several additions to the Azure Insights (Operational Insights in this case I believe) to include the following:
– Added cmdlets
– Add-AutoscaleSetting
– Get-AutoScaleHistory
– Get-AutoScaleSetting
– New-AutoScaleProfile
– New-AutoScaleRule
– Remove-AutoscaleSetting
– Get-Metrics
– Get-MetricDefinitions
– Format-MetricsAsTable

If you haven’t clicked on the link at the top yet, head on over to the Web Platform Installer or the Windows Standalone installer to get moving forward with the 0.8.16 build of the Azure PowerShell commandlets.

Also, if you’re using Visual Studio, there was a point release update to version 2.5.1 that might be of interest to you – .NET SDK for Visual Studio.

Happy PoShing!

Categories
Infrastructure

Blocking the installation of SharePoint 2013…

Recently I came across a thread on SPYAM regarding whether it’s possible to block SharePoint 2013 installations using group policy or through the registry.

Sure enough it’s possible to use the SharePoint 2010 installation blocking technique for SharePoint 2013 with a minor modification. Rather than having the Registry Key be for 14.0, just modify it to be 15.0.

So the key that end up implementing either through Group Policy, Power Shell or Registry key setting is:

HKLMSOFTWAREPoliciesMicrosoftShared ToolsWeb Server Extensions15.0SharePoint

With a DWORD Value of ‘DisableInstall’ with a property value of 1.

Sure you can still install the pre-reqs for 2013, but when you attempt to install the actual SharePoint 2013 binary, this is what you end up with:

SharePoint2013-BlockInstall

Time to pick up that VOIP handset and call the administrator about the GPO that seems to be pushed to my server and why I should be allowed to be moved to another OU that has a different domain linked policy. 🙂

Categories
Administration Troubleshooting

Automation of Password Updates…

Recently I stumbled upon a SharePoint 2010 environment setup a long time ago where the managed accounts and accounts in general were setup a little funny… in particular the issue was that the profile service stopped syncing. I asked the administrator what the issue was and they stated that they’d setup the system to use a managed account for the farm service account and other service application service accounts to automatically change the password in the background. That’s all fine and dandy for the most part, ‘cept that there are caveats with the Farm Account. And low and behold, I checked and sure enough the system’s Farm account was setup now as a Managed Account in our trusty, friendly SharePoint 2010 instance.

Issue – the profile synchronization service runs as this service account. Caveat, profile sync requires that you enter the account information and credentials since you may not necessarily be sync’ing with the Active Directory resource forest that your SharePoint system leverages as its Windows Networking Infrastructure platform.

So how did we attempt to remedy this… not knowing the Farm password, it was updated in Active Directory and then using Set-SPManagedAccount with the -UseExistingPassword argument, the password was properly updated. It was then synchronized across the farm with Repair-SPManagedAccountDeployment.

So SharePoint should now be up and operational with the managed account password updated, but we also have to go and update the synchronization connection with the new password. All should be working and fine, crisis averted, just have to go in Central Admin and make the update there… But, what I thought would be a five minute fix… well, yeah, not so much.

Hello 503 error.

Oddly, after all of the troubleshooting it ended up being the bitness setting for the Application Pool that operates SharePoint was modified to operate in x86 emulation mode. This comes in handy when you need to run two different compilations of a DLL through IIS, but with our native 64 bit SharePoint application, this doesn’t work so well. Why does this happen though? Not certain but it would seem that several folks seem to have this problem when they’ve been running their SharePoint system with managed accounts automatically updating and then reverting back to an “unmanaged mode” so to speak where the metabase becomes corrupt and suddenly the fitness for x86 emulation is set to true.

More on running in both x86 and x64 mode is available here: http://blogs.msdn.com/b/rakkimk/archive/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes.aspx

Please only modify this if you’re running into this problem – definitely make a backup copy before making any changes!!!

So if I want to avert this, I can force the Application Pool to start in 64bit mode by adding a “bitness64” flag… this is done in the ApplicationHost.config located in

%windir%system32inetsrvconfig

Within the Global Modules section of the ApplicationHost.config, you should search for the SharePoint14Module which should look something like this:

<add name=”SharePoint14Module” image=”C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14isapiowssvr.dll” preCondition=”appPoolName=SharePoint Central Administration v4″ />

If you want to force your App Pool to always start without x86 emulation… then you’ll want to add the following argument of “bitness64” so that you end up with something like this:

<add name=”SharePoint14Module” image=”C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14isapiowssvr.dll” preCondition=”appPoolName=SharePoint Central Administration v4,bitness64″ />

Note you’ll have to do this for each of the Web Applications that are registered – if you choose to make this modification.

And just like that… I start the application pool and all is well. Went and updated the synchronization connection and our UPS started syncing again. Qed.

More on ApplicationHost.config available here: http://learn.iis.net/page.aspx/124/introduction-to-applicationhostconfig/