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:

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.

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:

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. 🙂

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.