@meetlei

An Enterprise Service Bus (ESB) is a shared messaging layer that gives you a consistent, scalable and flexible means of coordinating across disparate, loosely-connected services to execute business processes. Over the years, Microsoft has developed several service bus technologies:

BizTalk: A messaging and workflow orchestration platform to build ESB behaviors and capabilities. The BizTalk ESB toolkit provides a set of guidelines, patterns and tools.

Windows Azure Service Bus (ASB): This provides the messaging infrastructure for applications that live in the cloud, in your data center, and crosses all devices and PCs.

Service Bus for Windows Server (SBWS): SBWS is based on ASB and shares many of the same capabilities, such as queue, topic and subscription support. A distinct design goal is to ensure symmetry between SBWS and ASB and allow for a single set of code to be leveraged across both deployment environments.

Read More…

Darrin Brandon

Have you ever wanted a fresh SharePoint development environment? Have you ever needed to quickly create a test box, or wanted to prototype something specifically for a customer? In the past, in all of these scenarios, you’d face a very time-consuming process and quite honestly, one that has likely been a deterrent. In this blog post, I’m going to walk you through creating a SharePoint 2013 development environment, on Azure, utilizing the Visual Studio 2013 RC.

Thanks to the good people at Microsoft, there is now a developer image on Azure that comes with SharePoint 2013 and Visual Studio 2013 Ultimate RC, already installed. Before we get too far along, I do have to warn you that you’ll need either an Azure or MSDN subscription. If you don’t have an Azure subscription, you can activate your MSDN Azure benefit and receive up to $150 USD in free, monthly Azure credits. If you are careful to shut down your VM at the end of each work day, then you should be able to use this VM as your day-to-day development machine without eating up all of your credits. Read More…

Abijith Kumar Yadugiri

Introduction by Vishwas Lele:

Amazon Web Services (AWS) CTO Werner Vogels offers this great piece of cloud advice: “Treat everything as a programmable resource, including data centers, networks, compute, storage and load balancers.” In other words, automate every aspect of your (cloud-based) infrastructure. There are significant benefits in following Werner Vogels’ advice:

You can build systems that are cost aware by only keeping the parts of the system that are needed and turning off everything else .
Capacity planning is hard. It is much better to dynamically build capacity based on the need.
Failures are not an exception but a rule. Rather than building complex logic to handle exceptions, make your systems fault resilient by provisioning failover resources as needed.
Make your systems more agile – systems that can scale in the direction of business vs. a design time scaling criterion.

Given AIS’ years of experience with SharePoint, we are always looking for ways to make the underlying infrastructure more cost effective, scalable and robust. Fortunately, the aforementioned benefits of automation apply equally to a SharePoint 2013 farm hosted in the cloud — whether it is the ability to dynamically provision a SharePoint 2013 farm on the fly, or the ability to scale up and down based on load, or the ability to make the SharePoint 2013 farm more fault resilient.

But it all begins with developing robust automation scripts to provision and manage a SharePoint 2013 farm. This brings us back to the purpose of this blog post by Abhijit Kumar. Abhijit discusses an automated approach for provisioning a SharePoint 2013 farm using Amazon Web Services. It is noteworthy that the automation approach we describe below is based solely on PowerShell. This might come as a surprise given that AWS offers services like CloudFormation, which enables creation of AWS resources, combined with open source tools such as Opcode Chef and AWS Puppet, which enable the installation and configuration of applications. We chose to rely solely on PowerShell for the following reasons:

PowerShell is Microsoft’s canonical task automation framework, consisting of a command-line shell and a scripting language that has full access to COM and WMI, giving Windows administrators control over every aspect of Windows OS-based machines.
PowerShell scripting language is based on the .NET framework. This means a PowerShell script can take advantage of .NET framework enhancements such as Workflow Foundation (WF). We use WF extensively to manage long-running automation scripts.
AWS Cloud Formation is not available on AWS Gov Cloud. AWS Gov Cloud is an isolated AWS region designed to allow U.S. government agencies and customers with sensitive workloads to address their specific regulatory and compliance requirements. Given that AIS services a large number of customers with stringent regulatory and compliance requirements, we needed an automation approach that worked on AWS Gov Cloud.
If you read our earlier blog post about SharePoint 2013 automation on Windows Azure, you will notice that we have been able to achieve a high level of reuse between Windows Azure and AWS scripts for SharePoint 2013 scripts. While the WF-based provisioning logic is largely the same, Azure Service Management SDK calls are replaced with AWS Tools for Windows PowerShell. This reuse allows us the flexibility to offer our customers a choice between the industry leading IaaS platforms – AWS and Windows Azure.

Abhijth’s post below walks you through the script to deploy SharePoint 2013 Farm on AWS in an automated manner. I am confident that you will it useful. Please give the scripts a try and let us know.

Arun Mudiraj

The recent announcement about the general availability of Windows Azure IaaS comes with the following key enhancements:

Remote PowerShell is enabled by default when deploying Virtual Machine using PowerShell.
Availability of trial images such as SharePoint in the image gallery.

These enhancements make it easy to deploy a SharePoint Farm in an automated manner using PowerShell scripts.

The goal of this blog post is to walk you through such a script. Read More…

Andrew Bassett

Today I want to talk about a process we created for building out machines using Virtual Machine Manager (VMM) as part of our daily build process within Team Foundation Server (TFS).

As part of our nightly build process, we actually recreate the entire environment from scratch. We don’t use snapshots; we actually delete and provision a series of VMs. This may sound like overkill and I’ve seen other approaches that use snapshots and revert each night…and I think that’s great. Use what works for you. However, we wanted something that could not only exercise our code base, but also our scripts that we use for building our environment. In a way, this allows us to test both pieces at the same time.

At this point I should throw in the disclaimer that this blog post builds on one written by my colleague David Baber: Driving PowerShell With XML. We use the same XML-driven framework to build out our machines. In reality the process of removing and creating VMs is treated as just one “step” in our build-out process. Executions of other steps obviously follow, but this post is primarily concerned with standing up that environment. What happens next is up to you. Read More…

Vishwas Lele

@vlele

We recently deployed a five-node CRM 2011 topology using Windows Azure IaaS with the following objectives:

Understand how a multiple node CRM setup can be provisioned using Windows Azure IaaS. Specifically, how the networking capabilities offered by the Windows Azure platform (i.e. stateless load balancing) map to the CRM requirements.
Develop an automated way to provision and de-provision a CRM setup. This is not only useful for dev and test scenarios, but also for production scenarios where it is notoriously difficult to conduct capacity planning before acquiring the necessary hardware. For example, it is hard to know upfront what CRM functional building blocks (aka CRM roles) the business stakeholders will want to focus on, such as async processes, sandbox, reports, etc. By dynamically scaling out the “needed” features on demand, we can enhance the business agility of the CRM.
Offer our customers an educated choice between CRM Online (no setup costs but less control) and CRM On-Premises (extensive setup costs but complete control).
Take advantage of hybrid apps that combine CRM capabilities with Windows Azure services, such as Windows Azure Active Directory, mobile services, etc.

Sam Larko

@SPSamL

We’ve reached the end of this series. In part one, we discussed the basics of PowerShell. Part two showed some of the ways to interact with SharePoint via PowerShell. Today we’ll look at parts of a script I compiled to build out a SharePoint 2013 development virtual machine.

Environment and Build Notes

I want to start off with some notes about the assumptions I took and the configuration I used. First, this VM is running in Hyper-V on Windows 8 and uses Windows Server 2012 which was installed through the GUI. (I’ll try to figure out PowerShell remoting and Hyper-V at a later date, but that wasn’t in the cards for this post.) Second, I’ve configured two virtual networks, one internal with a static IP and one external with a dynamic IP. I configured those through the GUI as well. However, almost everything else has been built using PowerShell. While we’ll only highlight some of the script in this post, you can find the full script at my CodePlex Project: Useful PowerShell Cmdlets.

David Baber

PowerShell is great. It’s a powerful tool/programming language that can help you automate and solve any number of challenges. However, PowerShell files can also get quite ugly. With functions, parameters, inclusions (of other files and libraries) and all sorts of comments, making necessary changes can feel like looking for a needle in a haystack.

I worked on a project recently and saw this ugly side firsthand, through thousands of lines of PowerShell script. Scripting spread out over dozens of files. I fought to learn the pattern of execution, and discovered that making even simple changes had side effects in processes that I didn’t even know were related. To overcome this, my team began using an XML file to maintain the list and order of commands to execute, and then had a simpler, generic PowerShell file to execute everything.

Today, our configuration has grown complex, supporting the installation and configuration of several enterprise software components that need to exist in concert with each other. Even with the complexities in the XML, it is easy to trace an error to the problem step, make corrections, and continue.

In this post we will lay down a foundation for anyone to build upon and organize their own PowerShell execution process cleanly inside of XML.

Sam Larko

@SPSamL

The first post in this series covered the basics of PowerShell including variables, loops, and decisions. It also introduced a few scripts I’ve used over the last several weeks. In this post, we’ll discuss how to use PowerShell in a SharePoint farm, some of the more useful capabilities (especially to developers), and a few more scripts that I’ve written to bring the topics covered together.

Integrating PowerShell With SharePoint

PowerShell has been natively supported in SharePoint since SharePoint Foundation 2010 and SharePoint Server 2010. When SharePoint is installed, in addition to the Product Configuration Wizard and Central Administration shortcuts, a shortcut for the SharePoint Management Shell is available. This application is a PowerShell console with a blue background and the SharePoint Snap-in loaded. The PowerShell Snap-in is a PowerShell version 1 object that, when loaded, makes additional functions (or cmdlets) available to call in the current PowerShell session. To do this, simply execute the following:

Add-PSSnapin "Microsoft.SharePoint.PowerShell"

This will allow you to access the SharePoint cmdlets in any PowerShell session. It’s also important to run the PowerShell or SharePoint Management Shell console as administrator as the logged-in user may only have limited access to the SharePoint farm.

Sam Larko

@SPSamL

When I apply for speaking engagements, I usually submit at least one session that will require me to learn a new language or technology. I did this with the upcoming SharePoint Saturday Austin with a session titled “PowerShell for Developers: IT Pros Need to Share.” This session is the catalyst for this three-part blog series, which will be published over the next few Fridays. This first post is intended to get everyone up to speed with the basics of PowerShell.

What is PowerShell?

PowerShell is a command-line language built on the Microsoft .NET Framework. This is a ridiculously simplified explanation, though. PowerShell is a task automation tool that takes common command-line languages and magnifies their power exponentially through the use of Cmdlets. Cmdlets are verb-noun commands that perform computer and application management tasks. These tasks can be as simple as restarting the computer or changing the time zone.

PowerShell is a sophisticated development language that contains many of the constructs found in other modern languages. Variables, functions, looping, and decision statements are all present among other important features. We will discuss these features and how they function in this post. Read More…

Industries

Capabilities

BlogPosts tagged with “PowerShell” - Page 2

Environment and Build Notes

Integrating PowerShell With SharePoint

What is PowerShell?