AzurePack: Components for Website Feature failed to install

I had to install a new Frontend and Publishing server for my Web Sites components inside Azure Pack, unfortunately the installation failed so I had to find out what was wrong.

First check on the troubleshooting step by step list is to control the Firewall, which also revealed the problem:

The automatically created Firewall Rule for the “WebFarmAgentService” which is used to install the rest of the components, only enables the rule for “Public interfaces”. So my interface that’s being used, that’s connected to the Domain, did not obviously allow that traffic.

Enabling “Domain” in the Firewall Rule solved the problem, and the installation went through! I can’t see any reason for the devs to make that decision to only enable the rule for Public… But maybe there is some strange reason that you guys can come up with?

 

Azure Pack : Database creation failed with internal server error

If you experience problems creating MS SQL Databases as an Azure Pack tenant, with the very descriptive error message “Database creation failed” and details “internal server error” you may have run into the same problem I had today.

Azure Pack states that the user needs to have a 8 character complex password, but in truth it’s using the settings from the Local Security  Policy on the MS SQL Server, which in my case was 12 characters long. So any attempt to create a database with username and a password shorter than 12 characters gave that error message.

Quick solution, set a new Local Security policy with length of at least 8 characters. Problem Solved!

 

Can’t access a computer remotely without password?

I got a question the other day, “how can i access a computer remotely without a password?”

The reason that it’s by default is not possible to access a computer remotely with an account that does not have a password is because there is a new security policy/feature which states:

You can change that behavior by modifying the “Local Security Policy” here:

NoPassword

 

Just a thought. One could argue that it’s actually safer to have no password on the Local Admin account and leave this policy Enabled. Than have a weak password on the Admin account.

Because if there is no password, no malicious person or software could ever remotely access the computer as a local admin. While if you have a weak password, it would be possible for someone to brute force (try all possible combinations until you get in) the password.

 

 

Hello world!

Welcome to my new Blog Site which will cover Geek Stuff in my life, mainly related to Windows and Microsoft infrastructure things that I find interesting in my work.

I’m working for TrueSec as an Executive Response Engineer, which is kind of the same role I had when I was working for Microsoft with Critical Problem Solving on site at customer.

Besides doing troubleshooting of critical (or not so urgent) problems, and normal consulting jobs, I’m also a MCT (Microsoft Certified Trainer) delivering trainings related to Windows and Security.  Both Microsoft Official Courses and more in-depth Mastering classes at Labcenter in Sweden and Truesec Inc in the States.