About Jeremy Pavlov

Jeremy is just a regular guy that likes to occasionally tell the world about stuff.
Thanks for digging in to more of what I've written...

Coretek Wins! – 2018 Citrix Innovation Award for Partners

2018-01-10T01:32:24+00:00 January 10th, 2018|Azure, blog, Citrix, Cloud, Microsoft, Micrsoft Cloud Solution Provider|

We won the 2018 Citrix Innovation Award for Partners!!

Thank so much to Wolverine Worldwide, all the people that voted for us, and of course all the awesome Coretek teammates that made it happen.  Much more to come!

See the details here:

https://www.citrix.com/go/innovation-award/partner-innovation.html

Amazing Video for 2018 Citrix Innovation Award Nomination…

2018-01-07T15:17:04+00:00 January 7th, 2018|Azure, blog, Citrix, Cloud, Micrsoft Cloud Solution Provider|

As nominees for the 2018 Citrix Innovation Award, Coretek recently had a video crew come through the main office.  The crew was there to interview, get scenery footage, and generally get the “vibe” of how we do what we do.

In the video, we get the overview of the amazing work we did with Wolverine Worldwide, helping them solve what is quite a common modern problem in an uncommon and innovative way.  And it is also really cool to see my fellow Coretekers “movie” extras!

Here is the completed video:

Please take a moment to watch the extremely cool video, and vote for Coretek for the 2018 Citrix Innovation Award Nomination at this link.  Then, if you like what you see, drop us a line and get Coretek and Citrix working to help you do what you do more efficiently!

Coretek’s Own 2018 Nutanix Technology Champions…

2017-12-21T13:38:53+00:00 December 21st, 2017|blog, Cloud, Nutanix|

We’re proud to share that our amazing fellow Coretekers Aaron Evans and Todd Geib have been nominated to the Nutanix Technology Champion (NTC) program for 2018!

http://eapch37923.i.lithium.com/t5/image/serverpage/image-id/3944iB069FBEB74F154B1/image-size/large?v=1.0&px=600

The NTC is an award that recognizes Nutanix and web-scale experts for their ongoing and consistent contributions to the community and industry. But it’s more than just an award — NTC is a program that also provides nominees with unique opportunities to further expand their knowledge, amplify their brand, and ultimately help shape the future of web-scale IT.

For more information on the program, please click here to visit the NTC 2018 announcement page.

Aaron and Todd have a combined 5 years in the program.  Props to Aaron and Todd for continuing to be a driving force behind Coretek’s commitment building Enterprise Clouds!

Initial Domain Integration Discovery…

2017-11-16T03:12:56+00:00 November 16th, 2017|blog, Domain Integration, PowerShell, Scripting|

If you are intending to be involved in an Active Directory Domain integration with Quest Migration Manager for AD, there are some simple AD attribute discovery checks you should do long before you get serious about such things as user counts and remediation and so forth.  And especially if you’re going to perform an Enterprise multi-Domain integration (many-to-one), its even more critical that you map out your attributes that you will be using for merging & matching the user objects across each domain relationship.

Attribute Analysis

Here at Coretek, we do a lot of Organizational and Enterprise Active Directory integrations, and many of them involve Quest Migration Manager for AD (MMAD).  Just today I was working with a customer to gather some of this early info, so I thought I’d post a note on some of these simple tests so you, too, can run them and see if your AD is in good shape to take on such a project.

The Quest Migration Manager for AD requires that you use a pair of Unicode String attributes for each domain relationship.  The default attributes used in a simple non-Exchange migration are “adminDescription” and “adminDisplayName”.  However, the more common scenarios I see involve Exchange and also multiple domains, requiring the use of other attributes such as “extensionAttribute14” & 15 and others.

The most common scenario I get involved with is where the users have already been created in the destination domain (due to an HR automation or other project), and the user objects from the source domain(s) will be merged, rather than created fresh.  In these cases I typically try to get the customer to check for these following critical things at a pre-project state — or as early as can be done — for the set of user objects that are to be part of the migration/integration:

  • Existing sidHistory — In most cases, existing sidHistory attributes on a user object are just a part of an old migration and may not matter.  However, if something like a previous Exchange migration was left un-complete, the sidHistory might be a critical part of the mailbox access for those users… and removing it without planning would be bad!  Tread carefully!
  • Existing extensionAttribute14, 15, etc. — These are the attributes that are commonly used in Enterprise AD migrations, and you’ll often find them still left-over from previous projects.  Those old project-based values don’t matter on their own; however I’ve also seen these attributes quite commonly used for other semi-hidden administrative items.  Why?  Because in Exchange environments, there’s a nifty GUI capability for editing these attributes, putting them at the fingertips of people that would otherwise leave them alone.  Again, make sure they are free and won’t be overwritten by anyone!

PowerShell Queries

So let’s check for these attributes, and below are some simple ways to see if anything is populated for those critical attributes.

To return a simple list of all user distinguishedNames with “sidHistory” populated with something (command is all-one-line):

(Get-ADUser -Filter {sidHistory -like "*"} -SearchBase "ou=MyOweYou,dc=doemane,dc=lowcull").distinguishedName

…then of course, you can swap out extensionAttribute14 for others… and replace the “.distinguishedName” with others, and we could format the output differently, dump to a CSV, etc.  Here is a similar search, but now we’re formatting the output to a table for easier quick reading (command is all-one-line):

Get-ADUser -Filter {extensionAttribute14 -like "*"} -SearchBase "ou=MyOweYou,dc=doemane,dc=lowcull" -Properties sidHistory,extensionAttribute14 |ft -Property name,sidhistory,extensionattribute14

…or, to pull it all together into one command and search for all three of the attributes I mentioned, do this (command is all-one-line):

Get-ADUser -Filter {(extensionAttribute14 -like "*") -or (extensionAttribute15 -like "*") -or (sidHistory -like "*")} -SearchBase "dc=doemane,dc=lowcull" -Properties sidHistory,extensionAttribute14,extensionAttribute15 |ft -Property name,sidhistory,extensionattribute14,extensionattribute15

Of course, you’ll want to change out the specifics in the commands above to match your domain info and attribute discovery needs, but you get the idea.

I hope that helps get you closer to your domain integration…  And I hope you let us help you out!

 

Azure – Which Public and Private IPs are In Use and By Which VM…?

2017-08-03T03:01:59+00:00 August 10th, 2017|Azure, blog, Cloud, PowerShell|

In my recent thread of simple-but-handy Azure PowerShell tools, I realized one important thing was missing: A tool that grabbed all the public & private IP addresses in use by VMs (plus some additional info).

I searched around, and found an old post by fellow Coreteker Will Anderson, where he’d solved the problem.  Unfortunately, PowerShell had changed since then, and his suggestion didn’t work anymore.  Fortunately however, Will Anderson is now on the other end of Skype from me, so after a quick explanation he gave me some advice on how to fix it within the new PowerShell behavior.  And of course, it would just be wrong not to post if back to the community…

So here is my script, with help from Will and another blogger Rhoderick Milne, where I found some additional input.  When executed, this script writes some quick handy info to screen, as in this lab example:

…which might be enough for you if you just want a quick review, but then it also dumps my preferred info for each VM to a csv, as follows: “Subscription”, “Mode”, “Name”, “PublicIPAddress”, “PrivateIPAddress”, “ResourceGroupName”, “Location”, “VMSize”, “Status”, “OsDisk”, “DataDisksCount”, “AvailabilitySet”

Just paste the below  into a script file, change the subscription name in the variable to your choice, and execute.  If you don’t know which subscription name to use, you can always run “Get-AzureRmSubscription” after you run “Login-AzureRmAccount” and find it in the list.  So grab the code, hack at it, and let me know where you take it!

# Thanks for help from Will Anderson, Rhoderick Milne for the assistance.
#
# Get Date; Used only for output file name.
$Date = Get-Date
$NOW = $Date.ToString("yyyyMMddhhmm")
#
# Variables
$MySubscriptionName = "Windows Azure  MSDN - Visual Studio Premium"
$VmsOutFilePath = "C:\temp"
$VmsOutFile = "$VmsOutFilePath\VmList-$NOW.csv"
#
$NeedToLogin = Read-Host "Do you need to log in to Azure? (Y/N)"
if ($NeedToLogin -eq "Y")
{
  Login-AzureRmAccount
  Select-AzureRmSubscription -SubscriptionName $MySubscriptionName
}
elseif ($NeedToLogin -eq "N")
{
  Write-Host "You must already be logged in then.  Fine. Continuing..."
}
else
{
  Write-Host ""
  Write-Host "You made an invalid choice.  Exiting..."
  exit
}
#
$vms = Get-AzureRmVm 
$vmobjs = @()
foreach ($vm in $vms)
{
  #Write-Host ""
  $vmname = $vm.name
  Write-Host -NoNewline "For VM $vmname... "
  Start-Sleep 1
  $vmInfo = [pscustomobject]@{
      'Subscription'= $MySubscriptionName
      'Mode'='ARM'
      'Name'= $vm.Name
      'PublicIPAddress' = $null
      'PrivateIPAddress' = $null
      'ResourceGroupName' = $vm.ResourceGroupName
      'Location' = $vm.Location
      'VMSize' = $vm.HardwareProfile.VMSize
      'Status' = $null
      'OsDisk' = $vm.StorageProfile.OsDisk.Vhd.Uri
      'DataDisksCount' = $vm.StorageProfile.DataDisks.Count
      'AvailabilitySet' = $vm.AvailabilitySetReference.Id }
  $vmStatus = $vm | Get-AzureRmVM -Status
  $vmInfo.Status = $vmStatus.Statuses[1].DisplayStatus
  $vmInfoStatus = $vmStatus.Statuses[1].DisplayStatus
  Write-Host -NoNewline "Get status `("
  if ($vmInfoStatus -eq "VM deallocated")
  {
    Write-Host -ForegroundColor Magenta -NoNewline "$vmInfoStatus"
  }
  elseif ($vmInfoStatus -eq "VM stopped")
  {
    Write-Host -ForegroundColor Yellow -NoNewline "$vmInfoStatus"
  }
  elseif ($vmInfoStatus -eq "VM generalized")
  {
    Write-Host -ForegroundColor Gray -NoNewline "$vmInfoStatus"
  }
  else
  {
    Write-Host -ForegroundColor White -NoNewline "$vmInfoStatus"
  }
  Write-Host -NoNewline "`)... "
  $VMagain = (Get-AzureRmVm -ResourceGroupName $vm.ResourceGroupName -Name $vmname)
  $NifName = ($VMagain.NetworkProfile[0].NetworkInterfaces.Id).Split('/') | Select-Object -Last 1
  $MyInterface = (Get-AzureRmNetworkInterface -Name $NifName -ResourceGroupName $VMagain.ResourceGroupName).IpConfigurations
  $PrivIP = $MyInterface.privateipaddress
  $vmInfo.PrivateIPAddress = $PrivIP
  Write-Host -NoNewline "Getting Private IP `($PrivIP`)... "
  try
  {
    $PubIPName = (($MyInterface).PublicIPAddress.Id).split('/') | Select-Object -Last 1
    $vmPublicIpAddress = (Get-AzureRmPublicIpAddress -Name $PubIPName -ResourceGroupName $Vmagain.ResourceGroupName).IpAddress 
    Write-Host -NoNewline "Getting public IP `("
    Write-Host -ForegroundColor Cyan -NoNewline "$vmPublicIpAddress"
    Write-Host -NoNewline "`)... "
    $vmInfo.PublicIPAddress = $vmPublicIpAddress
  }
  catch
  {
    Write-Host -NoNewline "No public IP... "
  }
  Write-Host -NoNewline "Add server object to output array... "
  $vmobjs += $vmInfo
  Write-Host "Done."
}  
Write-Host "Writing to output file: $VmsOutFile"
$vmobjs | Export-Csv -NoTypeInformation -Path $VmsOutFile
Write-Host "...Complete!"



I hope that helps!

Azure – What tags are we using again…?

2017-07-27T00:00:55+00:00 July 7th, 2017|Azure, blog, PowerShell|

Have you wondered what tags are assigned to all your Azure VMs?  Do you not have ARM Policies in place to enforce your preferred tags yet?

I was in just such a situation the other day.  Just like in my previous post on quick Azure-related scripts, I was working with a customer that just wanted a quick utility to report on what VMs are properly tagged (or not) in their implementation, without having to fish around the Portal.  No ARM Policies there yet…  *yet*.

So I whipped this together.  And much like that previous script, you just paste this into a PS1 file, set the subscription name in the variable, and then run it.

# GetVmTags - Jeremy Pavlov @ Coretek Services 
# Setting the subscription here
$MySubscriptionName = "My Subscription"
# Set some empty arrays
$vmobjs = @()
$vmTagsKeys = @()
$vmTagsValues = @()
# Get the VMs...
$vms = Get-AzureRmVm 
#
$NeedToLogin = Read-Host "Do you need to log in to Azure? (Y/N)"
if ($NeedToLogin -eq "Y")
{
  Login-AzureRmAccount
  Select-AzureRmSubscription -SubscriptionName $MySubscriptionName
}
elseif ($NeedToLogin -eq "N")
{
  Write-Host "You must already be logged in then.  Fine. Continuing..."
}
else
{
  Write-Host ""
  Write-Host "You made an invalid choice.  Exiting..."
  exit
}
#
foreach ($vm in $vms)
{
    Write-Host ""
    $vmname = $vm.name
    $MyResourceGroup = $vm.ResourceGroupName
    Write-Host "Checking tags for VM $vmname... "
    Start-Sleep 1
    $vmTags = (Get-AzureRmVM -name $vmname -ResourceGroupName $MyResourceGroup).Tags
    $vmTagsCount = $vmTags.Count
    if ($vmTagsCount -gt 0)
    {
      $vmTagsKeys = $vmTags.Keys -split '
[\r\n]' $vmTagsValues = $vmTags.Values -split '[\r\n]' for ($i=0;$i -lt $vmTagsCount; $i++) { $CurrentTagKey = $vmTagsKeys[$i] $CurrentTagValue = $vmTagsValues[$i] Write-Host -ForegroundColor Green "Key : Value -- $CurrentTagKey : $CurrentTagValue" } } else { Write-Host -ForegroundColor Yellow "No tags for $vmname" } }

The results should look something like this, except hopefully a lot more serious and business-y:

Have fun with it, change it up, and let me know what you do with it…   I hope it helps.  Enjoy!

Azure – Next Available IP Address…

2017-06-01T19:53:53+00:00 June 15th, 2017|Azure, blog, Cloud, PowerShell|

The other day, I was working at a customer location with one of their IT admins named Jim, designing an Azure IaaS-based deployment.  During our session, he challenged me to make an easy way for him and his coworkers to see if a particular address is available, or find the next available “local” address in their various Azure VNets.

Because while addressing can be handled with ARM automation — or just dynamically by the nature of IaaS server creation — in an Enterprise it is usually necessary to document and review the build information by a committee before deployment.  And as a result, Jim wanted to be able to detect and select the addresses he’d be using as part of build designs, and he wanted his coworkers to be able to do the same without him present.  So, this one is for Jim.

I wanted to write it to be user-friendly, with clear variables, and be easy-to-read, and easy-to-run.  …unlike so much of what you find these days…  😉

Copy these contents below to a file (if you wish, edit the dummy values for subscription, Resource Group, and VNet) and run it with PowerShell.  It will do a mild interview of you, asking about the necessary environment values (and if you need to change them), and then asking you for an address to validate as available.  If the address you specified is available, it tells you so; if it is not, it returns the next few values in the subnet from which the address you entered resides.

# TestIpaddress - Jeremy Pavlov @ Coretek Services 
# You just want to know if an internal IP address is available in your Azure VNet/Subnet.
# This script will get you there.  
#
# Pre-reqs:
# You need a recent version of the AzureRm.Network module, which is 4.0.0 at his writing.  
# You can check with this command: 
#     Get-Command -Module azurerm.network
# …and by the way, I had to update my version and overwrite old version with this command:
#     Install-Module AzureRM -AllowClobber
#
# Some things may need to be hard-coded for convenience...
$MySubscriptionName = "My Subscription"
$MyResourceGroup = "My Resource Group"
$MyVnet = "My VNet"
#
Start-Sleep 1
Write-Host ""
Write-Host "Here are the current settings:"
Write-Host "Current subscription: $MySubscriptionName"
Write-Host "Current Resource Group: $MyResourceGroup"
Write-Host "Current VNet: $MyVnet"
Write-Host ""
$ChangeValues = read-host "Do you wish to change these values? (Y/N)"
if ($ChangeValues -eq "Y")
{
  Write-Host ""
  $ChangeSub = read-host "Change subscription? (Y/N)"
  if ($ChangeSub -eq "Y")
  {
    $MySubscriptionName = Read-host "Enter subscription name "
  }
  Write-Host ""
  $ChangeRg = read-host "Change resource group? (Y/N)"
  if ($ChangeRg -eq "Y")
  {
    $MyResourceGroup = Read-host "Enter Resource group "
  }
  Write-Host ""
  $ChangeVnet = read-host "Change Vnet? (Y/N)"
  if ($ChangeVnet -eq "Y")
  {
    $MyVnet = Read-host "Enter VNet "
  }
}
#
try
{
  $MySubs = Get-AzureRmSubscription
}
catch
{
  Write-Host ""
  Write-Host -ForegroundColor Yellow "Unable to retrieve subscriptions."
}
$MySubsName = $MySubs.name
Start-Sleep 1
Write-Host ""
if ($MySubsName -contains "$MySubscriptionName")
{
  Write-Host "You are logged in and have access to `"$MySubscriptionName`"..."
}
else
{
  Write-Host "It appears that you are not logged in."
  Write-Host ""
  $NeedToLogin = Read-Host "Do you need to log in to Azure? (Y/N)"
  if ($NeedToLogin -eq "Y")
  {
    Login-AzureRmAccount
    Select-AzureRmSubscription -SubscriptionName $MySubscriptionName
  }
  elseif ($NeedToLogin -eq "N")
  {
    Write-Host "You must already be logged in then.  Fine. Continuing..."
  }
  else
  {
    Write-Host ""
    Write-Host "You made an invalid choice.  Exiting..."
    exit
  }
}
#
Start-Sleep 1
Write-Host ""
Write-Host "We will now check to see if a given IP address is available from any subnet in VNet `"$MyVnet`" "
Write-Host "...and if it is not available, provide the next few available on that subnet."
Start-Sleep 1
Write-Host ""
$MyTestIpAddress = Read-Host "What address to you wish to test for availability?"
#
$MyNetwork = Get-AzureRmVirtualNetwork -name $MyVnet -ResourceGroupName $MyResourceGroup
$MyResults = Test-AzureRmPrivateIPAddressAvailability -VirtualNetwork $MyNetwork -IPAddress $MyTestIpAddress
$MyResultsAvailableIPAddresses = $MyResults.AvailableIPAddresses
$MyResultsAvailable = $MyResults.Available
#
Start-Sleep 1
if ($MyResultsAvailable -eq $False)
{
  Write-Host ""
  Write-Host -ForegroundColor Yellow "Sorry, but $MyTestIpAddress is not available."
  Write-Host ""
  Write-Host -ForegroundColor Green "However, the following adddresses are free to use:"
  Write-Host ""
  $MyResultsAvailableIPAddresses
}
else
{
  Write-Host ""
  Write-Host -ForegroundColor Green "Yes! $MyTestIpAddress is available."
}
Write-Host ""
Write-Host " ...Complete"

Now, if you know a better way to handle it, or have tips for improvement — or if you find a bug — I’d love to hear them (and so would Jim).  I hope it helps you out there…

Thanks, and enjoy!

Walk for Wishes 2017…

2017-07-27T00:00:58+00:00 May 8th, 2017|Announcements, blog|

We did it again!  As the 19th Annual Walk For Wishes ® approached, fellow Coreteker Sarah Roland (a Walk veteran since 2011) assembled set up her annual “Sarah’s Dream Team” and put out the call for participation, as she has done every year since 2013.  And again this year, fellow Walk veterans Avi Moskovitz (since 2016) and I (since 2013) got our families involved and headed along to the Detroit Zoo and joined in the effort.

We are proud to have been a small — but important — part of the more than $500,000 and counting because of the efforts of more than 6,500 walkers combined!  It was a really great crowd, and there were tons of interesting things to do and see along the way (it’s the Detroit Zoo, after all), supported by care and food volunteers along the way.   And given some threatening weather, we were amazed that we also managed to get the whole day in with no rain, and just a bit of cold.  That’s 5 years in a row of good walking weather; someone must be watching out for us…

We are truly thankful to the folks at Coretek who donated so generously to us and our team, both individually and as a company, raising over $1400 with us by walk time.  We hope you are as moved as we are by the work that is done by the organization and the good that it brings to those that — in many cases — don’t have a whole lot of good in their lives at the moment the wish fulfillment is granted to them.  For instance, here’s the moment that Wish kid Emily discovered at the Walk that she was heading to Walt Disney World® Resort in about a month!

Wish kid Emily discovered at the Walk that she was heading to Walt Disney World® Resort in about a month!

And did I mention that you can still donate to our team!?!?  Just click here go to Sarah’s Dream Team page and follow the process to donate to the team or any of us individually.

Oh, and by the way… we decided that we are on a mission to get more members of our team for 2018, so you may as well just plan to join now…  😉

See you then!

5 Tips for connecting your Azure space to On-Premises…

2017-07-27T00:00:58+00:00 March 26th, 2017|Azure, blog, Cloud, Micrsoft Cloud Solution Provider|

Often, the easiest thing about using the Azure Cloud is getting started.  Whether it’s creating a VM, establishing a web service, etc., it’s usually as easy as a few clicks and you’ve got some “thing” running in a bubble.  That’s the easy part.

It’s what you do right after that can often be a challenge, since in many cases it involves inter-connectivity with your on-premises environment.  And at that point, whether it’s the early on, or even after long-thought-out deliberative designing, you may want to sit down and have a talk with your firewall/network team (who may never even have heard the word “Azure” before) and talk about exactly how to connect.

Please be mindful that the router/firewall people roll in a different workspace, and may have a different approach to what you’re trying to accomplish.  They may prefer to use third-party firewall/tunnel capabilities with which they are already familiar, or utilize the off-the-shelf options that Microsoft provides.  Note: This article is all about the built-in Microsoft options; we’ll have a discussion about third-party items in a future article.

Specifically when working with the native Azure connectivity options, the first thing you’ll want to do is point yourself and others at this URL, which provides most everything needed to get started:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-plan-design

…note that there are some great sub-pages there too, to take the conversation from “Why are we doing this” to “What is Azure” to “Let’s submit a ticket to increase our route limitation“.

But speaking as a server/cloud guy, I wanted to give you some simple but important tips you’ll need to know off the top of your head when speaking to your router people:

Tip #1
There are two types of Gateways for on-prem connections to the cloud: ExpressRoute and VPN.  ExpressRoute is awesome and preferred if you have that option.  If you don’t know what ExpressRoute is already, you probably can’t afford it or don’t need it — which leaves you with VPN.  The good news is that if done right, the VPNs can be perfectly fine for an Enterprise if you set them up right, and mind them well.

Tip #2
I’m mostly writing these VPN options down because I always forget it, but you need to know the definitions too:
“Static Routing” used to be called “PolicyBased” and your router person knows it as IKEv1
“Dynamic Routing” used to be called  “RouteBased” and your router person knows it as IKEv2

Tip #3
PolicyBased can only be used with “Basic” SKU, and only permits one tunnel and no transitive routing.  You probably do not want this except in the most simple of configurations.  Ironically, your router/firewall person will most likely configure your VPN this way if you don’t instruct them otherwise.  Watch out!

Tip #4
The firewall you have may not be supported.  But even if it’s not, that means two things:  you may be forced into PolicyBased (read Tip #3), or in many cases it will work just fine even if it’s not supported.  But you might be on your own if you have a problem, so know what you’re getting into.

Tip #5
Please calculate the total number of routes and gateways and such that you’ll be permitted based on the SKUs you’re chosen.  Make sure that your fanciful networking dreams will all come true when you finally get where you’re going.  Everything in Azure has a quota or limitation of some sort, and you can almost always get them raised from the low original limit, but some things just aren’t possible without changing SKUs.

Extra Bonus Tip
Look into the “Network Watcher” preview for validating some of your networking flow and security, and for an instant dashboard of the quotas (mentioned in Tip #5).  It’s only available in some locations right now, but it’s looks like it will be quite nice.

…and that’s just scratching the surface, but those are some of the things I run into out there, and I thought it might save you a minute… or a day… or more…

Good luck out there!

Enterprise Best Practice does not necessarily equal Cloud Best Practice…

2017-07-27T00:00:58+00:00 July 28th, 2016|Azure, blog|

This article might just be restating the obvious for some — but to put it bluntly, a “best-practice” Enterprise Active Directory (AD) design feature may not perfectly translate to a Cloud-based deployment scenario. Let me explain…

When Good Mappings Go Bad

Let’s imagine an enterprise that has done a good job of providing universal access to user Home Folders by using the AD Home Folder attributes on the user objects.  Very common indeed, and very well loved in most cases.  In a well-designed infrastructure, the users get access to the Home Folder from almost anywhere in the world, and from a variety of platforms including local, remote, and thin/terminal access.

On top of that, imagine further that the environment utilized the individual logon script user object attribute to determine group memberships, deliver printers, and maybe even deliver a mapping or two.  All of this is fine (though arguably cumbersome) in a high-speed environment where the network inter-connectivity is not rate-limited or rate-charged.

Now however, let’s imagine being one of those users authenticating to an RDS/Terminal Server (session hosts) farm in a cloud-based domain instead of in the Enterprise.  Hmm.  Suddenly, different access and performance considerations appear when walking through that logon process.  For instance, while that Home Folder server may be reachable from that RDS farm, that lookup and access of the file server might very well be across a VPN pipe that is slow; or even if it’s fast, there may be a charge for egress data transfer as is the case with Microsoft Azure.  Oh, and that logon script will definitely hit the Domain Controller looking for all of what it needs to draw conclusions; and in the end, may attempt to map you to things you cannot even reach.

Can you solve this problem by putting domain controllers in the cloud?  Well, part of it — if you use good AD Site and Subnet configuration.  But you can’t escape the fact that your enterprise user objects may attempt to reach beyond those controllers and into the infrastructure to access what they must, and time-out on what they cannot (read: slow logon).

The GPO is your frienemy

And don’t even get me started on GPOs.  Yes, you know them, and you love them, and you use them to provide a rock-solid enterprise configuration for your users…  But what about those mandatory proxy registry settings that matter in the cloud?  What about those printer map settings?  What about those WMI evaluations?  The Item-Level Targeting?  And so on.

And then one day of course, there’s the one GPO setting that accidentally gets applied to those users that inexplicably wipes out their access to the application in the cloud-based RDS farm.

The bottom line is that again, things that may be prudent and reasonable in the Enterprise may be detrimental to the Cloud users’ experience.

So what can you do?

First, step back.  Ask yourself if your user logon process is clean, lean, and mean, and prudent for a Cloud-based experience.  It may very well be the case, but it likely is not.  So if you find that you’ve been a good and dutiful Enterprise admin and used Active Directory to tightly configure that user, you might be faced with a need to have a separate directory for your Cloud environment that is either replicated, integrated, or federated.  Which, for some organizations, may very well cause them to have to re-think security models (or at least re-imagine the ones they have), evaluate provisioning, and so on, as part of a larger Cloud Strategy.

Or, if your situation permits, you might be able to take advantage of the soon-to-be-released Azure Active Directory Domain Services, as long your design doesn’t run up against some of the limitations (I strongly recommend you read the FAQ and other documentation before deciding it’s right for you).

Now you’ve heard what to watch out for, but the options you utilize going forward depend on what you are trying to achieve.  Good luck out there, and let us know if we can help…

Load More Posts