Category: Words

Azure Support Plan discovery

Jeff Miles Leave a comment

I learned some things about Azure Support Plans recently.

A co-worker was tasked with adding an Azure Support Plan to a new subscription that was being created. So they went to portal.azure.com, clicked “Help and Support”, and then from the drop-down selected the new subscription ID.

Then they clicked Change Plan and added a Standard support plan. Upon investigation, this appeared to add a support plan to ALL subscriptions, which was scary. We don’t want to be charged 10x$100USD per month!

Working through a support case with Microsoft, I learned the following about support plans that cleared things up.

A support plan is tied to an Azure Account – the account that subscriptions are created under. The support plan is effectively its own subscription, not tied to individual subscriptions themselves. However, you won’t see it displayed this way in portal.azure.com.

It’s not until you log into https://account.windowsazure.com/Subscriptions that you see it itemized by itself and are able to view billing history for the support plan.

So if I have 10 subscriptions, and they are all created under one Azure Account (you can see this on the “Properties” page of your Subscriptions blade), then only a single support plan is needed.

This also clarifies why Microsoft’s instructions on removing a support plan describe to “Go to the portal, and click ‘cancel subscription'”.

When I thought that this was a per-subscription basis, that made me afraid we’d cancel our actual subscription. Knowing now that this is it’s own subscription, that text makes a lot more sense.

Intel Network Connections (ProSet) update or removal

Jeff Miles Leave a comment

Short-version: be very careful removing the Intel Network Connections software!

I’m working on a task to update NIC drivers and firmware on a Dell PowerEdge R630. It was decided during this process to remove the Intel ProSet software along with it’s generated sub-interfaces for VLAN purposes, and instead utilize switch-port configuration.

I went to uninstall Intel(R) Network Connections from appwiz.cpl, which contains ProSet. On this server, its version was 19.3.0.0. However, I quickly received an error stating that I needed to remove any Teams and VLANs. No problem, I was going to do that anyways so I went into the advanced properties of my NICs and removed the VLAN sub-interface. I wasn’t using any Intel teaming, but rather LFBO within Windows Server.

When I tried again, it still gave me the same error. I decided to try “Modify” on the uninstaller instead, and remove ProSET only.

This was successful, but then when I tried to install the latest version, it said it couldn’t update with this error:
Product: Intel(R) Network Connections — The installed version of Intel(R) Network Connections is not supported for upgrades. You must uninstall it before installing this version.

So I tried the full uninstall again, and this time it worked! Great, I’m thinking “Now I can proceed with the latest version”.

Except it removed ALL NIC config, including IP settings and advanced properties like Jumbo Frames and RSS buffer sizes.

Thankfully I had good documentation of the previous setup, and that should be your biggest takeaway if you’re reading this: always consider “what’s the worst that could happen” and then plan to mitigate that thing.

For future hosts, I left the old version of the software installed and manually updated drivers from the .INF files. Interesting to note, if you already have a higher version installed like Version 22.7, this behavior isn’t seen – you can install an update on top of it without having to uninstall.

 

 

 

Project Honolulu and Server Core

Jeff Miles Leave a comment

By now many IT administrators have heard of Project Honolulu from Microsoft. I must admit, when I heard the headline and initial talk about it, I book-marked the info intending to come back but didn’t really dig into it. I thought, “oh a revamped Server Manager.”

My perspective is all changed now.

I’m watching the “Windows Server: What’s new and what’s next” session from Ignite 2017. I have been following Aidan Finn’s blogging of Ignite sessions including this one in particular for the “What’s new” session, and recall reading his notes about Server Core being in semi-annual channel, but not Server GUI, so “you better learn some PowerShell to troubleshoot your networking and drivers/firmware”.

But now having watched the session myself, it makes Microsoft’s vision and a path forward here very clear to me.

Using Server Core allows an organization to reduce their surface area for vulnerability, streamline the size/frequency of Windows Updates, optimize performance and scalability on hardware, and stay up to date on the Windows Server cadence.

Project Honolulu makes using Server Core viable. This is the answer to the Windows system administrator saying “Server Core just doesn’t give me the visibility I need into my servers”. As Jeff Woolsey walks through the functions of Project Honolulu, it is obvious that THIS is where the visibility will be; no more RDP into individual servers to manage their roles, devices, and settings. No more MMC windows to open Event Viewer and Shares and other applets.

Now I’m excited.

NLB website behind Azure Application Proxy

Jeff Miles Leave a comment

This is a quick post noting the minimum steps required to get a network load balanced website in IIS accessible through Azure AD Application Proxy. I’ve recently set this up for Deltek iAccess, and after a bunch of minor issues and mis-configurations (which took me hours to find, of course) I thought it worthwhile to compile the information in one spot.

Note, when troubleshooting this process, many different items can be cached which causes problem solving to go down incorrect paths and assumptions. This was perhaps the most challenging part of getting this set up. You’ll likely need to use the following commands regularly, in addition to waiting for AD and DNS sync intervals, and re-testing some minutes after changes are made in the Azure portal.

  • net stop dnscache && net start dnscache
  • ipconfig /flushdns
  • klist purge

Assumptions in this post are that NLB is already configured and working, and the website (or at least a portion of it) uses integrated Windows Authentication (otherwise many of these steps are unnecessary).

  1. Determine your DNS records. We have split dns and so used the same name internally and externally: “webapp.domain.com”
    1. Create a CNAME in internal DNS for “webapp.domain.com” to point to your NLB cluster name
    2. Create a CNAME in external DNS for ‘webapp.domain.com” to point to the provided Azure Application Proxy name; likely something like app-domain.msappproxy.net
  2. In IIS on each web host, set “UseAppPoolCredentials” to True using Configuration Editor (or web config directly) for the path: system.webServer/security/authentication/windowsAuthentication
  3. In IIS on each web host, configure the application pool identity to a domain user service account
  4. Create an SPN delegation in AD to match your DNS name and this service account:
    1. SetSPN -S HTTP/webapp.domain.com domain\username
  5. Use this SPN “HTTP/webapp.domain.com” within the configuration of your Azure AD Application Proxy.
  6. Add this SPN entry on the Delegation tab of the Azure AD proxy connector object in AD. You would search for the domain user service account, and select the HTTP entry matching webapp.domain.com

Things you don’t have to do, discovered after some trial and error:

  • Use a CNAME vs A record for internal DNS; both should work properly
  • Configure “DisableStrictNameChecking” or “BackConnectionHostNames”, as these apply to NTLM only, not Kerberos
  • Grant NTFS permissions to the domain user service account on the web application files
  • Specify a specific hostname within IIS binding configuration
  • Add the NLB cluster server names to your proxy connector delegation tab

Reliance on Google

Jeff Miles Leave a comment

Before Google, would I have been able to do my job effectively?

I’ve been thinking about this question the past few weeks, after I saw it raised on a reddit post. If I was no longer able to use a search engine during daily work, what kind of impact would that have on my ability to perform my responsibilities?

The most immediate result that comes to mind is the lack of ability to pick up syntax corrections and small code snippets/examples. I would be forced to be more organized in keeping my own examples and comments, and likely purchase additional resources to reference. In the scope of PowerShell it wouldn’t be as bad, as the help system built within PowerShell is excellent.

I’ve built up enough experience and understanding about “how things work” that I would be able to succeed in my role, albeit certainly less efficient.

Overall, I think I’d do alright with the lack of the Google, because I’m curious by nature. I investigate and seek to understand the concepts of technology I work with, not just the steps 1-2-3 to put it in place. I look for inter-dependencies in these platforms, and build upon a body of knowledge in how all the pieces fit together.

 

My thoughts turned to knowledge transfer, and how I can model some of these skills I have attained with my team members. I expect that 20 years ago there was a much higher reliance on mentorship and relationship building in order to acquire the experience needed to deal with technology solutions, and I think the additional benefits of those relationships are lost on us in the workforce now.

How can I continue to exceed my own expectations, and help uplift my team members in their quest to do the same? Here are a couple minor ideas that have big implications:

  • Try, and sometimes fail
  • Exhaustively read documentation
  • Learn to dig for log files and packet captures
  • Write post-mortem documents for completed projects; what went right, what went wrong