Posting this here mostly for me so I can find this easily again:
I’m monitoring this URL, waiting for .NET 4.7 support to appear. I’m hopeful that we’ll see something early in 2017 Q4, but I won’t be holding my breath either 😉
TLDR; Azure OS Family 5 requires Remote Desktop passwords >= 10 characters. Anything less will cause your login to fail, repeatedly requesting that you re-enter your password.
I ran into an issue when upgrading an Azure application from OS Family 4 to OS Family 5. We have configured RDP for our development deployments. As part of that deployment, we had configured special passwords for each environment. Those passwords had a strong enough length when we added them a few years ago: 8 and 9 characters. OS Family 5 (Windows Server 2016) requires that the passwords are at least 10 characters long.
As a result, we found that the deployment went fine (no errors reported) but that we simply couldn’t log in post upgrade. Looking on the portal, we noted that one has to have a password of at least 10 characters to add Remote Desktop from the portal. We counted the characters in our passwords, adjusted lengths, and found we could login again.
TL;DR: Microsoft offered me a position on the Windows Azure Service Bus team and I took it. I’m ex-Microsoft and I reclaim my blue badge on February 11, 2013.
Longer version: From 2000 to 2006, I worked at Microsoft on MSDN and later on Indigo (WCF). The family loved living in Washington state and I loved my job at Microsoft. However, my wife and I don’t ever want to look at life and see ourselves doing things that we know we will regret. One of the things we were starting to regret was not letting our kids get to know their extended family. In 2006, my wife and I chose to return to the Midwest so that our three children (then 10, 5, and 3 years old) could get to know their cousins, aunts, uncles, and grandparents. Since 2006, we’ve been able to attend graduations, weddings, and generally get to visit family whenever the spirit moved us. We got to know everyone in our extended family quite well. As happens quickly, the families have seen their kids get older, other activities occupy more of their time, and this has limited the ease in all of us getting together. Essentially, Thanksgiving works great- everything else is a crap shoot.
Over the last 2 years, getting together just got tougher, so my family reevaluated our goals and wants. We decided we wanted to go back to the Pacific Northwest and I figured that, if I’m going to move there, why not work for Microsoft again? One of the teams I was interested in was the Windows Azure Service Bus team. They had an opening and after a nice, long day of interviews, they decided to take a risk on an RD and Integration MVP. I really clicked with the team, so I accepted the offer. This choice also allows me to work on one of the largest scale systems in the world on a product that ships on an Internet cadence. I’m extremely excited about this opportunity and can’t wait to get into the code.
I plan to continue recording courses for Pluralsight on the weekends and evenings- the authoring/teaching bug bit me back in 1998. Pluralsight provides a great way to scratch that itch.
Back in 1999, I officially gave up on the desktop computer. Since then, my personal machine has always been a desktop replacement quality laptop. I enjoy being able to take a powerful box wherever I go. This past December, I felt a need to get a portable machine that supported Windows 8 with multi-touch. I’m floored by how light a desktop replacement can be! I wound up with a Lenovo X230 tablet. The thing is small- 12.5” screen. I equipped it with a slice battery so that I can work a full day away from a power source. You can also easily enhance the box to make it a wonderful workhorse. I picked up the I5 configuration with the basic memory and HDD. About 2 hours after receiving the unit from Lenovo, the machine had:
- 16GB RAM (Crucial)
- 256GB mSATA SSD boot disk (Crucial)
- 512GB Samsung SSD
- Screen protector
- Windows 8
When in its docking station, the machine drives a 27” Planar touch screen over DisplayPort and a second regular 27” Acer monitor over a USB to DVI display adapter. For the past several weeks, I’ve been using this setup to get stuff done wherever I go. I’m impressed with how small and light the X230 is. Travelling with this little machine has been pleasant. It’s easy to get work done with it on a plane, including writing code. This machine also runs virtual machines like a champ, which has been helpful for me to get my experimentation done and in just learning new stuff.
I will acknowledge that this laptop is not for everyone. For me, it met some important requirements:
- Support multiple HDDs: I frequently rebuild my system due to the amount of beta software I tend to run. Keeping apps on one disk, data on another means I just need to reinstall my apps—the data is automatically available.
- Support a lot of memory: I use VMs a lot. 16 GB seems to be a good min bar for support, though I would have preferred 32 GB as is supported on the W520.
- Weighs little: I wanted something that was light. I’m getting older and the W520 kills my back when I carry it in a backpack. The x230 is just tiny—and the power supply is super small too!
- Airplane friendly: I like to write code on planes. The W520 wasn’t comfortable to use in coach. The X230 is alright in those small seats.
- Docking station: I don’t want to think about reconnecting monitors, USB, keyboard, mouse, microphone, and more when I want to sit at a desk with bigger screens to get “big things” done. Most of the light and portable machines don’t support docking stations. The X230 does.
Given what is coming out for ultralight laptops over the next 6 months, the X230 still looks like a great option. If you are doing Win8 development and need a touch device, or just want a nice, light development machine, I highly recommend this little beauty.
A little while ago, I was asked to write a post on some topic for the MVP Program blog. I suggested a post on Windows Azure Mobile Services titled Connected Apps Made Wicked Easy with Windows Azure Mobile Services. That post is up now. So excited!!!
I was recently asked what my opinion was on REST versioning, a few years after having written http://www.informit.com/articles/article.aspx?p=1566460 and after having recorded some stuff for Pluralsight on versioning as well. The questions were general purpose enough that I thought I’d share my answer on the blog. Here are the questions and my answers:
1. Given 2.5 years since the article, have you seen any shift toward one or the other method in the industry?
What I’ve seen in behavior is that people only change the URL for breaking changes. They try like crazy to always use the same endpoint for everything, including new functionality. I have seen a lot of uptake with the WebAPI bits released in .NET 4.5. Some companies have gone NUTS on the ability to negotiate content types, and this is for applications for big companies with thousands to millions of customers.
For APIs meant to be consumed by less process oriented folks, I see more APIs that just use JSON. The API owner then documents things for internal SDK development teams. What appears to happen is the internal SDK development teams ‘test’ the docs by building APIs in .NET, Ruby, PHP, Java, Objective C, and so on. When this phase is done, the QA’d REST documents and resulting SDK documentation is published. Development of an SDK seems to be done in an effort to make API adoption easier and to reduce the amount of support needed to get API consumers up and running.
If I was leading a REST API development project, I would design a good structure, document whatever the team did for the REST API, and then lean on the SDK as the only well supported mechanism for accessing the API. This move would let the team build a nice SDK without worrying about making sure everyone can understand the REST documentation. The reality is that most developers do not know and do not want to fully understand the intricacies of content negotiation, cache headers, and so on. They just want to build software. Your job is to worry about these things and a good SDK makes it easier for all users to do the right things.
2. If you were building a new API today what direction would you go?
I’m reading this as a SOAP question as well as a “how do I build a REST endpoint today?” question. The answer is: it depends. If I need the API to be consumed by internal endpoints, SOAP gives me a faster way to build things and, since the app is internal, it’s highly likely that transaction consistency, security, and an RPC-like calling convention fit in well with the existing needs. I’d still version endpoints as much as I could, but reality is that most places roll out new versions of systems that need to be versioned in lockstep due to business and regulatory concerns that versioning simply does not care about. Oftentimes, the reason for the new version is new requirements that make the old version obsolete.
For external APIs, I’d only ever use HTTP based APIs. Then, the question is obviously: do you create new media types and use content negotiation, do you use new endpoints for version changes, or do you use something else? My preference today is to use new endpoints and worry about wiring things up correctly under the covers. Doing this allows me to monitor usage of each version using existing HTTP log scraping tools and seeing which URLs are being used most heavily. For everything else: how RESTful I am vs. just using HTTP as an RPC mechanism, data types, payloads, and so on, I’d stick with building SDKs as the preferred method to interact with the service. I value good design but I hate arguing about things like whether or not the ETags are configured correctly. The SDK documents the API team’s decisions where those arguments happened and let’s everyone else just use things.
3. Do you know of any particularly good resources on the topic of the top of your head that don’t come up in google and bing?
Actually, no. It seems like a lot of great stuff was written about designing REST APIs and what I’ve found on the various search engines all seems pretty decent. Today, tools like WebAPI from Microsoft and others make it easy to do the right things as an API developer.
Many folks have constraints in their data centers, frequently relating to which incoming and outgoing ports they can open up. Many times, they are restricted to only using well known ports, like HTTP (80) and HTTPS (433). When using the Windows Azure Service Bus and just using the defaults, you get some unexpected behavior. The Service Bus will still use TCP ports to do some of the back channel conversations such as keep-alive type polling that occurs to redirect requests from the Service Bus to your instance of the hosted service. To fix this up, you need to do one simple thing: tell the ServiceBusEnvironment to only use HTTP. In your application startup code, add this line so that Service Bus only speaks over ports 80/433:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
If you are on IIS, this code would go in the Application_Start override of global.asax.cs. If you are self-hosted, this goes into your main() method as one of your first lines of code.
If you want to troubleshoot and see if this is indeed the cause of your issues in your data center, look at the ports your application is opening up. Ports in the 7390-7395 range are coming from Service Bus. You’ll be able to detect this through your network monitoring infrastructure or tools like WireShark. Make the change I suggest, then check again. Your port issues should be resolved.