:'
This Azure CLI script is for ad hoc deploying customized Azure vms for testing including
- specified numebrs of vms and
- optionally a Bastion subnet for RDP/SSH over TLS directly with the Azure portal
To deploy,
1. Update the CUSTOMIZATION section, as preferred
2. Start an Azure Cloud Session,
https://docs.microsoft.com/en-us/azure/cloud-shell/overview
3. Set the target subscription, if different form the current one
4. Copy and paste the statements of CUSTOMIZATION and STANDARDIZED ROUTINE to the Azure Cloud Shell session
© 2020 Yung Chou. All Rights Reserved.
'
# Session Start
az login
az account list -o table
subName='mySubscriptionName'
az account set -s $subName
################
# CUSTOMIZATION
################
prefix='da'
totalVMs=1
vmSize='Standard_B2ms'
region='southcentralus'
#az vm list-skus --location $region --output table
bastionSubnet='no'
# osType is a required setting
vmImage='ubuntults'
osType='linux'
#vmImage='win2016datacenter'
#vmImage='win2019datacenter'
#osType='windows'
# For testing
adminID='hendrix'
adminPwd='4testingonly!'
:'
Password must have the 3 of the following:
1 lower case character, 1 upper case character, 1 number and 1 special character
# if to interactively set
read -p "How many VMs to be deployed " totlaVMs
read -p "Enter the admin id for the $totalVMs VMs to be deployed " adminUser
read -sp "Enter the password for the $totalVMs VMs to be deployed " adminPwd
'
ipAllocationMethod='static'
# Use '' if not to open a service port
ssh=22
rdp=3389
http=80
https=443
#################################
# STANDARDIZED ROUTINE FROM HERE
#################################
echo "
Prepping for deploying:
$totalVMs $osType $vmImage vms in $vmSize size
each with $ipAllocationMethod public IP adderss
and port $ssh $rdp $http $https open
"
tag=$prefix$(date +%M%S)
echo "Session tag = $tag"
rgName=$tag
#echo "Creating the resource group, $rgName..."
az group create -n $rgName -l $region -o table
#az group delete -n $rgName --no-wait -y
# VIRTUAL NETWORK
vnetName=$rgName'-net'
subnetName='1' # 0..254
nsgName=$rgName'-vnet-nsg'
nsgRule=$rgName'-TestOnly'
priority=100
#echo "Creating the vnet, $vnetName..."
az network vnet create -g $rgName -n $vnetName -o none \
--address-prefixes 10.10.0.0/16 \
--subnet-name $subnetName --subnet-prefixes "10.10.$subnetName.0/24"
# Bastion subnet
if [ $(echo $bastionSubnet | tr [a-z] [A-Z]) == 'YES' ]
then
#echo "Adding the Bastion subnet..."
az network vnet subnet create --vnet-name $vnetName -g $rgName -o none \
-n AzureBastionSubnet --address-prefixes 10.10.99.0/24
fi
# NSG
#echo "Creating a NSG, $nsgName, associated with the vnet, $vnetName..."
az network nsg create -g $rgName -n $nsgName -o none
#echo "Creating a NSG rule, $nsgRule, associated with the NSG ,$nsgName..."
az network nsg rule create -g $rgName \
--nsg-name $nsgName \
-n $nsgRule \
--protocol Tcp \
--access Allow \
--priority $priority \
--destination-port-ranges $ssh $rdp $http $https \
--description '*** FOR TESTING ONLY, NOT FOR PRODUCTION ***' \
--verbose \
-o table
# VM
time \
for i in `seq 1 $totalVMs`;
do
vmName=$tag'-vm'$i
echo "Prepping deployment for the vm, $vmName..."
osDiskName=$vmName'-OSDisk'
nicName=$vmName'-nic'
vmIP=$vmName'-ip'
az network public-ip create -g $rgName -n $vmIP \
--allocation-method $ipAllocationMethod \
--verbose \
-o none
echo "Allocated the $ipAllocationMethod public IP, $vmIP"
az network nic create -g $rgName \
-n $nicName \
--vnet-name $vnetName \
--subnet $subnetName \
--network-security-group $nsgName \
--public-ip-address $vmIP \
--verbose \
-o table
echo "Created the $nicName with the $ipAllocationMethod public IP, $vmIP"
# CREATE VM AND RETURN THE IP
if [ $(echo $osType | tr [a-z] [A-Z]) == 'LINUX' ]
then
echo "Configuring the Linux vm, $vmName, with password access"
linuxOnly='--generate-ssh-keys --authentication-type all '
else
linuxOnly=''
fi
echo "Creating the vm, $vmName now..."
pubIP=$(
az vm create -g $rgName -n $vmName -l $region --size $vmSize \
--admin-username $adminID --admin-password $adminPwd \
--image $vmImage --os-disk-name $osDiskName \
$linuxOnly \
--nics $nicName \
--query publicIpAddress \
--verbose \
-o tsv
)
#az vm show -d -g $rgName -n $vmName -o table
echo "
Voilà! The VM, $vmName, has been deployed with the $ipAllocationMethod public IP, $pubIP
"
done
# Deployed Resources
#az network vnet show -n $vnetName -g $rgName -o table
#az network vnet subnet list --vnet-name $vnetName -g $rgName -o table
#az network nic list -g $rgName -o table
az vm list -g $rgName -o table -d
# Clean up
:' To clean deployed resources
az group delete -n $rgName --no-wait -y
'
Category Archives: virtualization
NIST Guidance on Container Security
Here, a selected few of NIST documents which I’ve found very informative may help those who seek formal criteria, guidelines and recommendations for evaluating containerization and security.
NIST SP 800-190
Application Container Security Guide
Published in September of 2017, this document (800-190) reminds us the potential security concerns and how to address those concerns when employing containers. 800-190 details the major risks and the countermeasures of container technologies include image, registry, orchestrator, containers and host OS.
Worth pointing out that in section 6 of 800-190 recommends organizations should apply all, while listing out exceptions and additions in planning and implementation to, the NIST SP 800-125 Section 5 recommendations in a container technology context.
NISTIR 8176
Security Assurance Requirements for Linux Application Container Deployments
Published in October of 2017, this document (8176) explains the execution model of Linux containers and assumes the attack model is that the vulnerability in the application code of the container or its faulty configuration has been exploited by an attacker. 8176 also examines securing containers based on hardware and configurations including namespace, cgroups and capabilities. Addressing the functionality and assurance requirements for the two types container security solutions, 8176 complements NIST 800-190 which provides the security guidelines and counter measures for application containers, .
NIST SP 800-180
NIST Definition of Microservices, Application Containers and System Virtual Machines
As of January of 2018, this document (800-180) is not yet finalized, while the draft was published in February of 2017 and the call for comments had ended in the following month.
The overwhelming interests on container technologies and their applications have energized organizations for seeking new and improved ways to add values to their customers and increase ROI. At the same time, as containers, containerization and microservices have become highly popular terms and over and over again being abused in our daily business conversations, the lack of rigorous and recognized criteria to clearly define what containers and microservices are has been in my view a main factor confusing and perhaps misguided many. For those who seek definitions and clarity before examining a solution, the agony of being in a state of confusion suffocated by the ambiguity of technical jargons indiscreetly applied to statements can be, or for me personally is, a very stressful experience. And some apparently has had enough and urged us that “There is no such thing as a microservice!”
With 800-180 serving a similar role to what NIST 800-145 to cloud computing, we now have a set of criteria to reference as a baseline for carrying out a productive conversation on containers., microservices and related solutions. And that’s a good thing.
NIST SP 800-125
Guide to Security for Full Virtualization Technologies
Like many NIST documents, this document (800-125) first gives the background information by explaining what full virtualization is, the motivations of employing it and how it works, before depicting the use cases, requirements and security recommendations for planning and deployment. Although today most business and technical professionals in the IT industry are to some degree versed in virtualization technologies. 800-125 remains an interesting read and provides an insight into virtualization and security. There are two associated documents, as below, point out important topics on virtualization to for a core knowledge domain of the subject.
- NIST SP 800-125A Security Recommendations for Hypervisor Deployment on Servers
- NIST SP 800-125B Secure Virtual Network Configuration for Virtual Machine (VM) Protection
Microsoft Nano Server with Docker Enterprise Edition (EE)
This article details the process to install the latest Docker EE Version 17.06.2-ee-3 to a Microsoft Nano Server. I am sure there are different ways to do this. After a few iterations, here is one verified approach. A sample script is available.
Background
As shown below, when adding the server feature, containers, in Windows Server 2016, it installs Docker EE Version 17.06-1-ee-2. As opposed to what is in Windows 10, adding containers in ‘Turn Windows features on or off’ of Program and Features of Control Panel installs Docker CE Version 17.03.1-ce, i.e. Community Edition. Information about the two versions is available. The latest version of Docker EE is 17.06-2-ee-3. To keep all Docker EE to the same and the latest version, one may need to manually install Docker EE, instead of employing the default version with a Windows Server. To manually install Docker EE to a Microsoft Nano Server, follow the steps provided below.
Windows Server 2016 patched on 10/05/2017
Windows 10 patched on 10/05/2017
Step 1 – Create a Nano Server vhdx file with the container package
First, use Nano Server Image Builder to create a vhdx file with intended packages including containers. Notice if Windows ADK (Assessment and Deployment Kit) is not in place, it will prompt for installing ADK. Which is about 6.7 GB download. Once ADK is in place, start the image builder which is wizard-driven and straightforward. I picked vhdx format for building a Gen2 VM. And as shown below, I also added containers, Hyper-V and Anti-Virus packages. The Windows Server 2016 media used to create the Nano Server vhdx file is en_windows_server_2016_x64_dvd_9718492.iso download from my MSDN subscription.
Step 2 – Update the Nano Server OS
In Hyper-V manager, I created and started a Gen2 VM using the vhdx created in Step 1. And log in the VM to find out the IP address, as shown below.
I did the following to connect to the host. Once connected, not shown in the following is that to test the Internet connectivity and update the DNS setting, as needed, by following the instructions in the sample script. What should be done first is to carry out a Windows update. Which I did.
For this particular VM, I had already updated the OS before taking this screen capture, thus there was no, i.e. zero, updates applicable. Originally there were two updates, KB4035631 and KB4038782, listed as applicable. This update took 20 minutes with about 2 GB download, followed by a reboot of the system. If there is an interest in examining the list of applicable updates beforehand, you can run the following in the PSSession before the Invoke-CimMethod in line 8,
$updateList = ($ci | Invoke-CimMethod -MethodName ScanForUpdates -Arguments @{SearchCriteria=”IsInstalled=0″;OnlineScan=$true}).Updates
Step 3 – Install Docker EE
If to simply use the Docker default to current Windows Server 2016 installation, which is Docker EE Version 17.06-1-ee-2, as stated earlier, install the provider and package will do. In this case, execute line 1 and line 4 to start a PSSession after updating followed by rebooting the OS, then run the following PowerShell commands to install Docker.
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name docker -ProviderName DockerMsftProvider
Restart-Computer -Force; exit
To manually install Docker EE Version 17.06.2-ee-3, I did the following:
After downloading and extracting the source file in line 27 and 28, the PATH in the registry was updated with the installation of Docker to persist the reference across sessions. Rather than reboot the system, the current PATH was updated to start and verify the installation of an intended version of Docker from line 39 to line 41. The following is the user experience of executing line 1 to line 41 and successfully installed Docker EE Version 17.06.2-ee-3.
In a swarm, keeping all Docker instances in the same version is essential. In case there is a need to have Docker EE Version 17.06.2-ee-3 in Windows workloads, the presented steps achieve that.
What’s Next
Having installed Docker EE, start pulling down images and building containers. Deploying a swarm in a hybrid setting is what I plan to share next.
An Introduction of Windows 10 Credential Guard
Windows 10 Enterprise has introduced a set of new security features including Credential Guard which is a key for securing derived credentials and defend ‘credential theft and reuse’ attacks like Pass-the-Hash (PtH) and Pass-the-Ticket. This article is to provide a technical background and highlights how Credential Guard works. A good reference titled “Protect derived domain credentials with Credential Guard” is also available in Microsoft TechNet Library. Note that Credential Guard is technically part of Device Guard to be detailed in an upcoming article.
LSASS, a Known Secret Service in Windows
Credential Guard is to secure the data kept by Local Security Authority (LSA) Subsystem Service (LSASS) which is a privileged process in Windows and for:
- Validating users for local and remote sign-ins
- Enforcing local security policies
And on an Active Directory domain controller, LSASS is also responsible for providing Active Directory database lookups, authentication, and replication. The following illustrates an instance of Windows 10 running OS Build 10586, while the desktop Task Manager reported the status of LSASS. Also hereafter, unless stated otherwise, LSA and LSASS are used interchangeably.
The above shows the Task Manager reporting LSASS.exe running in a Windows 10 Enterprise desktop prior to enabling Credential Guard.
The Secret Service’s Secrets
Those secrets for authenticating requests on behalf of users are hashes and Ticket Granting Tickets (TGTs) which the secret service protects. In this article, the focus is on a hash, while much of the information is applicable to TGTs as well.
Hash
The term, hash (or a password hash, a hash value), in the context of computer security is a derived credential, namely an encrypted form of a user’s plain text password. During a session, a protected resource upon being initially accessed by a user will first try to authenticate the user. And upon a successful authentication, the process then authorizes the request based on access rights granted to the user and those security groups the user is a member of for this resource. In Windows security model, a password is never stored in plain text, instead it first goes through a hash function, and the resulting hash value is what LSA stores for reuse in a subsequent authentication request. A password hash can be stored in one of four forms: LAN Manager (LM), NT, AES key, or Digest. Although over the years, recent versions of Windows do not store LM and NT hashes anymore, however for backward compatibility some out-dated applications may still cause which to be stored. Windows security model stores hashes in one of the two places:
- a local Security Accounts Manager (SAM) database
- a networked Active Directory database, as applicable, namely the NTDS.DIT of a domain controller
LSA Secrets
And based on the supported authentication protocols and methods of the OS, LSA loads corresponding authentication packages which know how to realize a particular hash. And as mentioned, there may be various hashes which LSA stores in an encrypted forms in the local device registry for various usage scenarios and backward supportability. These stored hashes and other security artifacts like TGTs are collectively referred as LSA secrets.
There is normally a time-to-live element associated with a hash. And before a stored hash expired, LSA can and will reuse it upon an authentication request, instead of repeatedly prompting the user for credentials, hence provide an SSO experience to the user. Detailed description of authentication artifacts and processes are beyond the scope of this article and available elsewhere.
Recently, SSO has become a crucial component for a baseline criteria for user experience and adopting an application. And as malware becomes increasingly sophisticated, LSA secrets have become targets for identity theft and reuse attacks with stealth.
Pass-the-Hash (PtH) Attack
Once a user is authenticated, depending on the scenarios, there are multiple forms of a hash, i.e. LSA secrets, stored in LSASS process memory on a user’s behalf. And there are also tools including PowerShell to extract them. A password hash is stored for subsequent authentication needs including storage access, network transmission, etc. for this user, rather than to repeatedly prompt the user for the password again during a session. This is significant for implementing SSO, at the same tim for identity theft and reuse as well.
What makes a hash an interesting hacking target is a stored hash represents an already authenticated user. Additionally, a hash can roam within a network for remote access. And by passing a hash when accessing a remote resource, an authentication process can proceed without the need to have the user whose password previously generated the hash aware of. Such that this attack can allow a hacker to traverse a network, infect the next note and look for higher value accounts. And repeat the process to eventually acquire an account with domain administrator rights to ultimately own the associated Active Directory domain. Notice that Accessing LSA secrets does require a local administrator-level access.
Conceptually, a PtH attack is to first hack a local administrator-level account for accessing LSA secrets, i.e. stored hashes, then impersonates a user by presenting the user’s hash for accessing a remote resource without the need to involve the user at all. Notice that from an OS point of view there is no difference if a hash is presented on behalf of a legitimate user or a hacker via unauthorized access. This is why a PtH attack is effective, hard to detect and an imminent threat to an entire network.
Ultimately, an unauthorized access to LSA secrets including password hashes and TGTs can lead to the so called PtH and Pass-the-Ticket (PtT) attacks, respectively. And accessing LSA secrets is a privileged operation and requires local administrator rights. In other words, to conduct a PtH attack a hacker must first hack/phish an account with local administrator rights.
Assume Breach Security Model
So to conduct PtH or PtT, a hacker will need to first acquire local administrator access. And it seems one logical and essential defense is to focus on protecting the credential of a local administrator account. This is a right approach, however not an effective way. Statistics has shown that many users uses the same password for accessing multiple sites, potentially corporate and external sites. With a rootkit which can be installed by a careless click on a phishing email, malware can potentially be loaded before OS code upon forcing a reboot and compromise a device at a boot time. Anti-virus, encryption, real-time monitoring, etc. are all based on a presumption that hardware and the loaded OS are trustworthy. This is apparently not necessarily always the case.
Today, with hundreds of thousands, yes, hundreds of thousands new malware everyday and the alarming infection rate which we have learned from the past, in addition to Advanced Persistent Threats (APTs) are on the rise, ensuring a device and its OS maintain a pristine state from power on to off is critical. IT has quickly learned in the past few years from some high profile breaches that getting hacked is a reality and highly likely once targeted. And a new normal for IT has become “You have been hacked, you just don’t know it yet.”
In other words, IT needs to essentially assume breach, and take a serious look on how to prevent PtH attacks in this setting. And the first has to be ensuring the hardware and the platform (i.e. OS runtime) are trustworthy.
First, Hardware Boot Integrity and OS Code Integrity
I put these two together since from a user’s point of view both seem appearing as one start-up process once powering on a device. By the time a user sees the welcome or logon screen and types in a user ID and a password, the OS has been loaded and the system processes are auto-started, delayed or stopped per associated configurations. An important presumption for security measures to work after a device starts has always been that collectively the hardware (i.e. firmware) is loaded without being tempered, the OS code is loaded without being altered and all defined processes are set as designed. In other words, for all the security measures like antivirus, security policies, etc. engaged or imposed after a device is booted to be effective, the device must maintain both hardware and platform integrity. So the runtime environment is trustworthy and with predictable behaviors to possibly monitor identify and detect malware.
Windows 10 Device Guard employs UEFI 2.3.1 secure boot and a number of measures to ensure boot integrity and OS code integrity. This is to be detailed in upcoming post and beyond the scope of this article. Here, the point is that a meaningful discussion of protecting hash values and defending PtH attacks must be based on a device with trusted firmware and OS code.
Protecting Derived Credentials (Hashes)
The introduction of Credential Guard in Windows 10 Enterprise edition offers a new approach to increase the security of derived credentials, i.e. password hashes and Kerberos TGTs, with virtualization-based securities to mitigate PtH and PtT attacks. There are various editions in Windows 10 for home, business and education users. Notice that Credential Guard is to better secure credentials in a managed and networked environment and does require Windows 10 Enterprise or Education edition.
Windows 10 Credential Guard Architecture
Credential Guard uses Virtualization-Based Security (VBS) to isolate secrets so that only privileged system software can access them. The following illustrates a conceptual model. There are particular hardware and configuration requirements as shown. Specifically, UEFI 2.3.1 or later is required and has a different disk partitions with those of BIOS. IT needs to plan the deployment of UEFI to those devices accordingly for employing Credential Guard.
Prior to Windows 10, all derived credentials are kept by LSA. The danger is that upon successfully compromising LSA, a hacker can get full access to LSA secrets. In Windows 10, the LSA is moved into a separate container serving as a VBS environment and runs as LSAIso. Windows 10 marks the first version of Windows to leverage hardware to create an area of high isolation. This makes it impossible for hackers to steal derived credentials. Let’s take a deeper look of VBS.
Enabling Credential Guard
In a Windows 10 Enterprise device, with UEFI Secure Boot and the hardware assisted virtualization turned on in the boot configuration, the settings are in the policy, as shown below.
VBS requires Secure Boot, and can optionally be enabled with the use of DMA Protections, as illustrated below. DMA protection requires hardware support and will only be enabled on correctly configured devices. On Code Integrity setting, this enables VBS to protect and ensure the integrity of Kernel Mode.
With Windows 10 Version 1511, Credential Guard now has an UEFI lock setting. IT should test the setting against management scenarios to ensure supportability. Once Credential Guard is enabled, after a reboot LSAIso.exe should run and appear in Task Manager, as shown below.
Concept of Virtualization-Based Security
With Credential Guard, the local LSASS now works with LSAIso, a new and isolated LSA process that runs, stores and protects in a virtualized, i.e. isolated, environment within the same device. Notice that LSAIso does not host any device drivers, but a small subset of OS binaries that are needed for security. All of these binaries are signed with a certificate that is trusted by VBS and these signatures are validated before launching the file in the protected environment. These measures make Windows 10 virtualization-based security highly secure with minimal attack surface.
Remote Procedure Call
When processing a hash, LSA issues RPC to LSAIso. RPC, a program communication model introduced in 1984, offers a mechanism allowing a program in one device to make a procedure call to a program/procedure running in a remote environment. The calling (or caller) program becomes suspended after making the call and resumed upon receiving the results passed back from the called (or callee) program. Essentially, RPC offers a mechanism which enables a distributed application appearing as if the entire application resides locally. The employment of RPC simplifies the logical design and facilitates the implementation of a distributed application.
From a PRC’s point of view, LSA and LSAIso are two processes running in two separated environments and isolated from each other. When processing hash, LSA perform a RPC call to LSAIso, and waits for LSAIso to passed back the results to continue. Notice the secrets stored by LSAIso are protected with VBS and is not accessible to the rest of the operating system. In other words, “who” can call “whom” for “what” and “how” in this model are well defined. Credential Guard further enhances security by not allowing older variants of NTLM and Kerberos authentication protocols and cipher suites when using default derived credentials, including NTLMv1, MS-CHAPv2, and weaker Kerberos encryption types, such as DES.
Closing Thoughts
Credential Guard isolates and protects LSA secrets against PtH and PtT which have become popular “credential theft and reuse” attacks. Like many other Windows 10 security features, Credential Guard does have specific hardware, software and configuration requirements. IT need to start planning early since the hardware and the UEFI Secure Boot requirements may require a hardware upgrade, a disk layout change from BIOS to UEFI, an architecture change from x86 to x64, etc. The immediate task is to build inventories and assess business needs for Windows 10 security features, followed by planning hardware refresh and rolling out UEFI sooner than later.
Be Strategic, While Facing a Growing Trend of BYOD
By itself, Credential Guard secures hashes which is an important, yet just one component for protecting identity and defending malware. In Windows 10, a suite of security features are available including Devise Guard, Windows Hello, Microsoft Passport and combined with Enterprise Mobility Management (EMM) suite offering a new approach on device security from power on to off. Such that IT has the ability to manage not only on-premises devices, but also BYOD-based deployment via cloud. The key consideration is to make sure all management solutions are in convergence, and not end up with one solution for on-premises, one for cloud, and one for mobile.
EMM is a key enabler for authenticating users and enforcing device policies via cloud. It is a vehicle to embrace BYOD with minimal changes needed on existing on-premises infrastructure. For a sizeable company, some form of EMM solution is evitable facing raid adoption of mobility and BYOD. IT leadership needs to develop a roadmap for adopting EMM sooner than later, and start transforming into a “mobile first, cloud first” operation model as Microsoft so passionately advocates.
Call to Action
- Learn Windows 10 which Microsoft Virtual Academy offers self-paced and free online courses in all Microsoft products, technologies and solutions including Windows 10, security and “Windows as a Service” as shown below.
- Download Microsoft Deployment Tool Kit (MDT) and build inventories of your current IT establishment, if not already.
- Review Windows 10 editions and assess business needs for security features and the hardware/software/configuration requirements.
- Take advantage of your hardware refresh to roll out UEFI, sooner than later.
- Plan and execute your Windows 10 deployment.
Microsoft Azure Stack Technical Preview 1: Introduction & Feature Overview
This is something I had wanted to do for a while. Finally did welcome Charles Joy, a Principal Program Manager on the Azure Stack team, back to the show and we discussed the recent release of Microsoft Azure Stack Technical Preview 1. It’s a fun episode. Enjoy it.
US TechNet on Tour | Cloud Infrastructure – Resource Page
This wave of TechNet events focuses on Azure (IaaS) V2, namely Azure Resource Manager or ARM. It is part of IT Innovation series currently delivered in US metros and many other geo-locations in the spring of 2016. For those outside of the US, go to http://aka.ms/ITInnovation to find out events near you. Come and have some serious fun in learning.
The presentations, available in PDF format, and the following lab material are included in this zip file.
GitHub repository for Lab Files if using your own machine
If you are not using the hosted virtual machine and are using your own workstation, any custom files the lab instruction call out can be found in a GitHub repository. The repository is located here: https://github.com/AZITCAMP/Labfiles.
Required Software
|
Description |
Steps |
|
Required software will be called out throughout the lab. |
|
Optional Software
|
Description |
Software |
|
Any additional software that you require will be called out in the lab. The following software may be useful when working with Azure in general. |
|
My Presentation at The Univ. of Texas at Arlington
It is a great pleasure to have an opportunity to meet the wonderful and vibrant student community and speak about cloud computing at UTA on October 8, 2015. I focused on making the point of why cloud and why now, demonstrated with the ability to constructing computing fabric and deploying application on demand.
http://www.microsoft.com/feeds/omni_external_blogs.js
Additional resources:
Moving Data In, Out and Between Azure Storage Accounts Using AzCopy
Try It Yourself, Application Deployment as a Service with Microsoft Azure PowerShell
In the last few months, I have taken a few opportunities to talk about deploying an application as a service. This is a subject with many aspects in connecting the concepts of cloud computing, application deployment process and IT operations. I find it also encompasses great frequently run routines for automation with Azure PowerShell.
Here I share the material which I have integrated into IaaS workshops I have recently delivered.
- Part 1 is the user experience which is also supplemented with published videos. (Channel 9)
- Part 2 highlights the PowerShell scripts I wrote to deploy the sample application. (Channel 9)
Announcing U.S. TechNet on Tour Events for Fall, 2015
You are invited to join us for free, interactive events led by Microsoft Technology Evangelists.
Cloud is making DR a feasible solution, technically and financially, for companies of all sizes by utilizing a cloud solution provider, i.e. someone else’s infrastructure. In these deliveries, attendees will learn the fundamentals of cloud and see how to employ Microsoft Azure as part of a wider disaster recovery (DR) plan! This is an opportunity to learn, experience and gain technical depth of DR, and network with IT pros in your areas and grow together.
Attendees will receive a free Microsoft Azure pass and spend most of the day in a hands-on lab environment. Customers should attend the event to learn:
Introduction to Microsoft Azure - Cloud Storage and Virtual Networks
- Virtual Machines
- Azure Site Recovery (ASR)
Who should attend: The event is technical by nature and is aimed at IT pros who get hands-on with technology as part of their day to day jobs. Previous experience of Microsoft Azure is beneficial but not essential. Here are the city registration links, dates and presenter. And we are looking forward to meeting you all.
| City | State | Event Date | Presenters |
| Seattle | WA | 9/1/2015 | Jennelle Crothers and Brian Lewis |
| San Francisco | CA | 9/3/2015 | Jennelle Crothers and Yung Chou |
| Houston | TX | 9/22/2015 | Kevin Remde and Yung Chou |
| Charlotte | NC | 9/29/2015 | Tommy Patterson and Yung Chou |
| Philadelphia | PA | 9/30/2015 | Dan Stolts and Blain Barton |
| Indianapolis | IN | 10/6/2015 | Brian Lewis and Yung Chou |
| Tampa | FL | 10/7/2015 | Blain Barton and Tommy Patterson |
| New York | NY | 10/8/2015 | Dan Stolts and Kevin Remde |
| Irvine | CA | 10/14/2015 | Jennelle Crothers and Yung Chou |
| Dallas | TX | 10/16/2015 | Kevin Remde and Yung Chou |
Get a head start with Azure today:
- Sign up Azure free trial with $200 usage credit
- Register for Microsoft Virtual Academy and start your learning
Witnessing a clear cloudy day every day 