Export Azure Routes to CSV via PowerShell

I needed a way of exporting all route tables within an Azure sub to a CSV in a format that could be used to recreate them if required. The following PS does the trick.

$rts=Get-AzureRmroutetable$rts=Get-AzureRmroutetable$outputfinal=@()foreach ($rt in $rts) { $routes=$rt.routes foreach ($route in $routes) { $Outputtemp = “” | SELECT VNETname,SubnetName,RTName,RGName,Location,RouteName,AddressPrefix,NextHopType,NextHopIPAddress
$separator = “/” $SubnetIDSplit=$rt.subnets.id.Split($separator)
$outputtemp.SubnetName=$SubnetIDSplit[-1] $outputtemp.VNETName=$SubnetIDSplit[-3] $outputtemp.RTName=$rt.name $outputtemp.RGName=$rt.Resourcegroupname $outputtemp.location=$rt.location $outputtemp.routename=$route.Name $outputtemp.AddressPrefix=$route.AddressPrefix $outputtemp.nexthoptype=$route.nexthoptype $outputtemp.NextHopIPAddress=$route.NextHopIPAddress $outputfinal += $outputtemp } }$outputfinal |export-csv .\route.csv -NoTypeInformation

Advertisements

Transitioning from Intune Hybrid to Standalone

So I recently had to take a customer from using Intune with SCCM to Intune Standalone. To complete this you have to log a call with Microsoft who will reset the MDM authority for you. The process requires a blank slate so you have to completely clear any mobile devices from SCCM before MS will go ahead. They provided the following action plan to be completed ahead of kicking off the MDM reset.

Steps to be performed:-

  • Retire all Modern Devices (mobile devices) from within the Configuration Manager Console. It is important that you do not attempt to retire a device from the device itself for this procedure to be executed. Let us Know if any devices are in a “pending state’ .
  • Set the Intune User Group in the Intune Subscription to be “blank”, restart SMS Executive, confirm in the CloudUserSync.log that all users are removed.
  • Delete the iOS APNs certificate
  • Delete any and all published applications that are for MDM Devices
  • Delete any and all polices that are for MDM Devices
  • Remove the Windows Intune Connector from within the Configuration Manager Console

Once you confirm this is completed MS will pass the request to the product team to complete. They quote 1 to 5 days for this but it ordinarily takes 2 days.

In my case we had to ask MS if they could go ahead without having cleared all the devices up front due to time pressures and they said they strongly recommended against it and we would be responsible for any problems caused. Apparently devices in this state when the authority is reset may not be able to enroll in future or receive policies correctly even if they do…

 

ADFS Authentication flow with Multiple Forests

So recently I had the time and motivation to try to understand exactly how authentication works in a multi-forest ADFS environment. In my case I was preparing to visit a customer that would need this kind of setup and wanted to brush up.

I couldn’t find any decent information on the web so thought I would share my findings here.

Scenario:
2 forests, forest A (IMTest) has ADFS and AAD Sync deployed and has a transitive forest trust with forest B (TestDomain)

Capture

I wanted to know when a user from TestDomain authenticates, does ADFS authenticate directly with a TestDomain DC by way of a Kerberos referral or does it go via a IMTest DC which authenticates the remote forest user on it’s behalf? Don’t forget ADFS is installed into the IMTest forest.

As a result of this then, does ADFS need any connectivity to the TestDomain DC’s?

I asked this question on a few forums and MS kindly came back and told me that all auth traffic would flow via the IMTest DC and no networking would be required between ADFS and TestDomain. However they didn’t really back it up and I wanted to be sure so I built a lab and set about testing.

I found that as soon as I blocked traffic between ADFS and the TestDomain DC my authentication for the TestDomain user broke throwing a random ADFS error. I checked the firewall logs and sure enough found some Kerberos and LDAP packets being dropped.

Capture2

So i installed WireShark onto the ADFS Farm server and the results were quite educational.

Capture3

So WireShark can be a little hard to interpret so lets talk through the highlighted sections.

  1. The ADFS server (10.0.2.4) send an AS-REQ to the IMTest DC(10.0.1.5). This is the Kerberos process of requesting a TGT (Token granting ticket) from the AS (Authentication Server)
  2. AS on the IMTest DC responds with KDC_ERR_WRONG_REALM. This is because the UPN suffix of the user does not belong to the IMTest forest but is associated with the TestDomain Forest trust. If we take a closer look at the contents of this packet we can see that the reply contains the new KDC to contact in the CRealm fieldCapture4
  3. So a new AS-REQ is sent but this time to the TestDomain DC (10.0.1.4)
  4. The TestDomain AS responds with ERR_PREAUTH_REQUIRED. This is expected behaviour as the client requested a ticket but did not include the pre-authentication data with it. Windows uses this technique to determine the supported encryption types.
  5. This is followed by another AS-REQ but this time containing the required authentication contained within the padata header of the packet.
  6. The TestDomain DC responds with AS-REP. This contains the TGT needed to continue and request service tickets. Here it is..Capture5
  7. So lets continue with the next Kerberos step of contacting the TGS (Ticket Granting Server) to ask for a service ticket. This is shown below in the TGS-REQ to the TestDomain DC but note the highlighted sname (Service name we are requesting access to) shows KRBTGT IMTEST.K1TECHNOLOGY.CO.UK. This is the TGT service in IMTest.Capture6
  8. The TestDomain DC responds with a TGS-REP which contains the service ticket.
  9. Next ADFS takes the service ticket and presents it to the IMTest DC but this time we are referencing SKFed…. This is ADFS.Capture7
  10. Voila Authentication is completed! Well, the user has been authenticated at least. The process is actually then repeated by ADFS to grant the user access to the ADFS service account principal. This is required in order to be able to do an LDAP bind and retrieve the account attributes it needs to evaluate the claim and build the ADFS token. Clearly there is another part where ADFS issues the client a token to take to Office 365 but that is well covered elsewhere on the web.

So what did I learn?

  • ADFS needs TCP/88 (Kerberos) and TCP/389 (LDAP) connectivity to every forest you plan to use it with.
  • Make sure your UPN suffixes are registered correctly in your forest trusts else the first Realm referral won’t work.
  • Finally it’s also important that ADFS is able to resolve each of these domains.

I hope this helps, it’s taken me almost a day of investigation to bottom this out but now I properly understand the authentication flow.

Thanks to Joji over at Technet Blogs for this post that helped me understand what I was looking at.

http://blogs.technet.com/b/askds/archive/2012/07/27/kerberos-errors-in-network-captures.aspx

VB Script to Apply Office 365 IE Settings

Am preparing to deploy Office365 to a small customer that has no AD environment so my usual method of applying these customizations via GPO was out the window.

Never fear a bit of googling later and I’ve come up with the following VB script which adds the appropriate sites to Local Intranet and Trusted Sites lists, creates shortcuts on the users desktops to the Office 365 portal and turns off the Automatically detect settings box from the connection settings which can cause trouble when using the Open with Explorer functionality of Sharepoint online.

Script;


rem Applies Office 365 IE Recomendations

rem - Add Trusted sites

AddTrustedSite "about:blank"
AddTrustedSite "https://*.outlook.com/"
AddTrustedSite "https://*.sharepoint.com/"
AddTrustedSite "https://*.microsoftonline.com/"
AddTrustedSite "https://*.lync.com/"

Function AddTrustedSite(strDomainName)

    Set WshShell = Wscript.CreateObject("Wscript.Shell")
    strRegKey = "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\"
    WshShell.RegWrite strRegKey & strDomainName & "\", "", "REG_SZ"
    WshShell.RegWrite strRegKey & strDomainName & "\*", "2", "REG_DWORD"
End Function

rem - Add Local Intranet sites

AddLocalSite "*.microsoftonline.com"
AddLocalSite "*.sharepoint.com"
AddLocalSite "*.outlook.com"
AddLocalSite "*.lync.com"

Function AddLocalSite(strDomainName)

    Set WshShell = Wscript.CreateObject("Wscript.Shell")
    strRegKey = "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\"
    WshShell.RegWrite strRegKey & strDomainName & "\", "", "REG_SZ"
    WshShell.RegWrite strRegKey & strDomainName & "\*", "1", "REG_DWORD"
End Function

rem - Create shortcuts - Modify yourdomain.sharepoint.com

set WshShell = WScript.CreateObject("WScript.Shell")
desktopFolder = WshShell.SpecialFolders("Desktop")
set link = WshShell.CreateShortcut(desktopFolder & "\Office365.url")
link.TargetPath = "https://login.microsoftonline.com/"
link.Save

set WshShell = WScript.CreateObject("WScript.Shell")
desktopFolder = WshShell.SpecialFolders("Desktop")
set link = WshShell.CreateShortcut(desktopFolder & "\Sharepoint.url")
link.TargetPath = "https://yourdomain.sharepoint.com/"
link.Save

rem - Disable Automatically detect settings option

Const HKCU = &H80000001
'Define variables
Dim strComputer
Dim strRegistryKey
Dim objRegistry
Dim strRegistryValue
DIm binValue
strComputer = "."
strRegistryKey = "Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections"
strRegistryValue = "DefaultConnectionSettings"
'Connect to the Registry
Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
'Retrieve the current settings.
objRegistry.GetBinaryValue HKCU, strRegistryKey, strRegistryValue, binValue
'Change the 'Automatically detect settings' box to unticked
binValue(8) = 01
'binValue(8) = 13 - Enable this line to check the box instead of uncheck
'Save the changes
objRegistry.SetBinaryValue HKCU, strRegistryKey, strRegistryValue, binValue

Exporting Recipient\Sender filtering lists

Today I needed to export the entries from the Recipient Filtering and Sender Filtering lists on a customers Edge environment. A quick scoure of the web and I found lots of scripts with broken download links. Anyway you can use the following commands to export your lists to a nice CSV 🙂

Get-SenderFilterConfig | select-object blockedsenders -expand blockedsenders | export-csv c:\senders.csv

Get-RecipientFilterConfig | select-object blockedrecipients -expand blockedrecipients | export-csv c:\recipients.csv

The Autodiscover Internal\External URL

I’ve learned a lot about Autodiscover recently, I’ve meddled with it for years but a recent project has taken me to new depths and I thought I’d offer one titbit of information that had me confused for a while.

The Autodiscover Internal and External URL’s as accessible via the Get-AutodiscoverVirtualDirectory cmdlet are not required in Exchange 2007 or 2010! They are a red herring in your quest to understanding how to publish Autodiscover correctly. In Exchange 2013 the Internal\External URL attributes have been deprecated from the AD Virtual directory which will save us all some confusion.

Access to Autodiscover is achieved internally using the Autodiscover URI which can be viewed using the Get-ClientAccessServer cmdlet and corresponds to the SCP records in AD that Outlook looks for if logged onto and talking to your domain.

Access to Autodiscover externally is nothing more than a DNS entry, Exchange doesn’t care per se how you reach it, its simply name resolution of autodiscover.yourdomain that leads the outlook client to your perimeter. Better description here http://technet.microsoft.com/en-us/library/bb332063%28v=exchg.80%29.aspx#OutlookAndAD

If you think about it why would an Autodiscover External or Internal URL be required, the entire purpose of the other CAS URL’s is as endpoints to the various Exchange services, if you are already fetching the Autodiscover.xml why would you need URL’s to talk to Autodiscover?

David

Bending an F5…

I was recently tasked with implementing an Exchange 2010 environment fronted by an F5 load balancer, sounds great right. One hitch the F5 was running version 10.2.0 and all over F5’s website and deployment guide they tell you that 10.2.1 is the minimum version for publishing Exchange 2010. http://www.f5.com/pdf/deployment-guides/f5-exchange-2010-dg.pdf

What does this really mean? From version 10 F5 have included Application Templates for various applications basically giving you a wizard for the otherwise very complicated configuration. In 10.2.0 the application template is missing a few vital components and contains a few errors, for various reasons the client I was working with couldn’t update so we had to try and make it work.

Tips;

  • Follow the pdf to the letter, I highly recommend using the provided info sheets.
  • You can only run the template once for all your services, ie you can’t fill in Outlook anywhere and then go back and add ActiveSync (On a shared IP at least) so make sure you do them all at once.
  • Auto discover is missing from the template, you will need to manually create the pool and monitor as per the appendix tables on page 68.
  • Ensure you complete all the modifications to the template, page 22. Take note of the multiple monitor accounts.
  • Beware the I-Rule on page 75, this rule is the bread and butter of how the F5 separates the CAS services if you are balancing them on a shared address. The URL’s included eg  “/microsoft-server-activesync” are case sensitive and incorrect in the I-Rule provided. This took us 2 full days to solve. Make sure they match your Exchange URL’s exactly.

If this helps one person past the same situation I’ll be a happy man, a week trying to get this F5 working and no content on the web makes for frustrating times.

David