DexterPOSH's Blog

While working with the REST API endpoints exposed by the leaders in MDM space (Hint - VMware acquired them) , I picked up few things on how to authenticate to the REST endpoints and would like to document those here. The post is generic about how to use the below Authentication schemes: Basic Authentication Certificate Based Authentication Basic Authentication In Basic authentication, we base 64 encode the UserName & Password and pass it in the header. Pretty straight forward on how to do it in PowerShell, S tore the Credentials and then just encode them : $Credential   =   Get-Credential $EncodedUsernamePassword   =   [System.Convert] :: ToBase64String( [System.Text.Encoding] :: UTF8 . GetBytes($( '{0}:{1}'   -f   $Credential . UserName ,   $Credential . GetNetworkCredential() . Password)))

Many of the Exchange Admins might already be familiar with the dreaded checkbox of doom , which causes issues with move request and Mobile devices. Post by MVP Tony Redmond here  explains this in detail. Scenario & the Problem at hand : When a User connects to the Exchange Server using his Mobile device, then after the authentication the Exchange Trusted Subsystem creates  msExchActiveSyncDevices Objects for the User. This will be evident from the below screenshot for one of the User in ADSI edit. Now what if the Exchange Trusted Subsystem doesn't have permissions on the AD User to create those Objects , all hell is let loose. This was the case I was tackling recently and searching each User in the Directory which had this checkbox of doom unchecked manually is not feasible (am lazy).

As already mentioned in my previous post , I now have a test Exchange 2010 Server running on Azure . Now working in Mobile Device & Email Management space, my mobile devices needed to eventually connect to my Email Infrastructure to try out few scenarios. Initially I thought that opening the https endpoint and enabling ActiveSync (for the Mailbox User) would suffice, but I was wrong. Needed to make few changes to the SSL bindings on the IIS and trust the certificate used for the same. Let's get to it then. When we create a new VM on Azure it gets the Certificate for the cloud service added to the machine's personal Cert store. Below is a screenshot showing the same : Now as mentioned in my previous post Exchange by default will create a self signed Certificate and bind it to the CAS Server for https communication.

A while back I had blogged about using PowerShell to create a playlist of random songs in VLC player & I had a rudimentary function based on that in my profile. 001 002 003 004 005 006 function   play-song {      param ( [int] $count = 5 ,   [string] $Path = "D:\Songs" )      Get-ChildItem   $Path   -recurse   -filter   *.mp3 |   Get-Random   -Count   $count   |          ForEach-Object   -process  {  Start-Process   $_ . Fullname  -verb   'AddtoPlaylistVLC' } } I know the name contains an unapproved verb but I was lazy to change it. Few days back I thought of extending above function a little bit, so that my laptop Sleeps when the songs in the playlist end (hopefully I would have slept by that time )

My recent dive into the Mobile Device & Email Management space has presented me with an opportunity to learn Exchange & Office 365. I have built up an Azure VM running Server 2008 R2 with Exchange 2010 Server on it. It didn't made a whole lot of sense to connect to the machine using RDP and then running cmdlets on Exchange Management Shell. Well I must admit that I tried opening a normal PSSession and importing the Exchange cmdlets in there but that didn't work as the Microsoft.Exchange endpoint configuration is hosted on IIS. So here are the steps I followed to get the Exchange cmldets via Implicit Remoting, this is very similar to what we do with Office 365. This is a beginner post as am still wrapping my head around Exchange ;) Open the endpoint on the cloud service to allow the HTTPS traffic to your Exchange Server. Here is how the endpoints appear for my Exchange box. Note that the Public and Private port are both 443 which means when I try reach my c...

In my previous post, I blogged about using Azure Automation to deploy a Windows 10  Server Technical Preview VM in my test domain running on Azure. But if you noticed there were lot of things that we needed to do from the Azure portal. Being an advocate of doing all things from PowerShell I gave it another shot and below is what I found (notice the colors based on what I was able to do with PowerShell)  : 1. Get the Ground work ready (few bits possible ) 2. Create the Assets  (not possible at the moment) 3. Create a RunBook to deploy the VM (and add it to the domain) (PowerShell Rocks !) PowerShell + Get the Ground work ready As already mentioned at the moment you can't create an Azure Automation account with PowerShell, but what you can do is add a new User to Azure Active directory :) You will have to review Software Requirements and then  install the Azure AD module   Once the module named " Msonline " is installed you can very well go a...

Recently VM running Server Technical Preview were added Azure Gallery and I thought of deploying a VM running it joined to my test domain (see my post on using PowerShell to deploy a DC on Azure ), But I wanted to do that using Azure Automation. Azure Automation is a highly scalable workflow engine offering where we can have Runbooks (PowerShell workflows) to automate long running , error prone tasks. I first saw this in action at one of the sessions by Ravi Sir [PowerShell MVP] at one of the PowerShell Bangalore User Group meet where he used Runbooks to demonstrate really cool stuff. Note - Azure Automation is still in preview so you might have to sign up for it by navigating to  https://account.windowsazure.com/PreviewFeatures Divided the post into 3 steps: 1. Get the Ground work ready 2. Create the Assets 3. Create a RunBook to deploy the VM (and add it to the domain) Get the Ground work ready First of all create an Azure Automation account from the portal (n...