Managing resources in the cloud seems to be the new frontier for the traditional IT departments within companies. We often talk about how we can make this easier for companies to do.
In my case, I have a small lab within Azure. What I want to be able to do is launch all the services in my lab on demand. After all, that is the real cost savings of moving to a platform like Azure. Spin up the servers when needed, use them, de-allocate them at the end of the day to save money. Small labs could be managed easily via the management console, but I needed a reason to try Azure Automation. Note that Azure Automation, at time of writing, is in preview mode and you need to request it on your subscription.
First things first, have a read at the official docs.
Step-By-Step Azure Automation
Runbook Management
At a high level, Azure Automation is built to run powershell-workflow scripts. Perfect fit if you don't want to run your own system center components, or other automation tools. You get charged by the hour an automation script is running.
Azure Automation makes use of "Automation Assets" in order to run. Basically, you can create connections and credentials and then, via powershell, use them to connect to an Azure subscription. Assets are also used to load modules into your powershell environment in the cloud, set variables that you can use globally, and also create schedules that you can then apply to runbooks or groups of runbooks.
At the outset, it seems to have all the basics for you to create a rich set of automation tools to help you manage your Azure subscription(s). It even provides an online editor with intellisense to help you create your scripts.
The Step-By-Step details some powershell scripts that you can use to connect to an azure subscription and stop a demo. I implemented essentially the same thing. You can find my code on GitHub. I hope to add more scripts as I move along.
Friday, July 11, 2014
Wednesday, July 2, 2014
RODC install issues
In certain areas of your expanded perimeter, installing an RODC has good security benefit. There are some issues that can occur when installing an RODC. It mostly has to do with the way AD works, but it is important to note.
Issue 1) Don't create the site before you add the DC.
In a recent RODC setup, we decided to "jump the gun" and add the site to sites and services before setting up the RODC. The problem with this is that you have to log in as a domain admin before you can promote a server. This act causes AD to pick a DC from the next closest site (since the site you setup doesn't have one yet) and add it's DNS records to the site. Once this is done, you are at the mercy of AD weights and priorities to determine which logon server you will use.
This article has more detail on the AD Locator process. The solution is to go through DNS and delete the appropriate records for the incorrect DC.
Issue 2) Be mindful of which passwords are allowed to replicate
Only passwords that are explicitly allowed and not explicitly denied are allowed to replicate. By default, the policy is quite restrictive, and with good reason. You are probably deploying an RODC in a semi-trusted segment. You probably don't want your schema admin password to be cached out there. There are tools built in to AD to help you figure out who is authenticated to the RODC, and to allow you to test a user to see if the password would allowed to be cached. You can also pre-populate passwords. This is all done via the AD user and computers snap-in.
Issue 3) Configuring Site Link Costs
Remember to change the costs of the site links! If you want AD to always choose your RODC (unless it is unavailable), configure the site link cost appropriately.
Issue 4) Cached DC
Once the DC Locator process runs, the result is cached on the machine. If you run into any of issues 1/2/3, you may be authenticating against the wrong DC. Fixing the issue at the server level doesn't solve the problem because the result is already cached.
You can check to see what DC is cached using the nltest command. You may have to copy the executable from a DC to a non-dc machine.
nltest /DSGetDC:<domain name>
To update the result, you can use
nltest /DSGetDC:<domain name> /FORCE
Issue 5) Use Azure data disks for the AD DS files
This issue is Azure specific, but probably a good location where you would want to deploy an RODC.
See this article
Although you shouldn't have an issue when you deploy an RODC, it is good to follow the best practices outlined.
Issue 1) Don't create the site before you add the DC.
In a recent RODC setup, we decided to "jump the gun" and add the site to sites and services before setting up the RODC. The problem with this is that you have to log in as a domain admin before you can promote a server. This act causes AD to pick a DC from the next closest site (since the site you setup doesn't have one yet) and add it's DNS records to the site. Once this is done, you are at the mercy of AD weights and priorities to determine which logon server you will use.
This article has more detail on the AD Locator process. The solution is to go through DNS and delete the appropriate records for the incorrect DC.
Issue 2) Be mindful of which passwords are allowed to replicate
Only passwords that are explicitly allowed and not explicitly denied are allowed to replicate. By default, the policy is quite restrictive, and with good reason. You are probably deploying an RODC in a semi-trusted segment. You probably don't want your schema admin password to be cached out there. There are tools built in to AD to help you figure out who is authenticated to the RODC, and to allow you to test a user to see if the password would allowed to be cached. You can also pre-populate passwords. This is all done via the AD user and computers snap-in.
Issue 3) Configuring Site Link Costs
Remember to change the costs of the site links! If you want AD to always choose your RODC (unless it is unavailable), configure the site link cost appropriately.
Issue 4) Cached DC
Once the DC Locator process runs, the result is cached on the machine. If you run into any of issues 1/2/3, you may be authenticating against the wrong DC. Fixing the issue at the server level doesn't solve the problem because the result is already cached.
You can check to see what DC is cached using the nltest command. You may have to copy the executable from a DC to a non-dc machine.
nltest /DSGetDC:<domain name>
To update the result, you can use
nltest /DSGetDC:<domain name> /FORCE
Issue 5) Use Azure data disks for the AD DS files
This issue is Azure specific, but probably a good location where you would want to deploy an RODC.
See this article
Although you shouldn't have an issue when you deploy an RODC, it is good to follow the best practices outlined.
Subscribe to:
Posts (Atom)