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…

Jack OConnell

Yesterday, Microsoft announced the general availability of its offering of Infrastructure as a Service (IaaS). They join an already-crowded market of IaaS providers, but this offering gives all companies the ability to offload workloads that have traditionally run in a company data center to the cloud. Welcome, Microsoft — the water is fine.

This announcement also represents a major chunk of Microsoft’s family of Azure offerings…and in my opinion, a stepping stone many companies simply must take in moving out of the traditional data center and into the cloud. The following diagram shows the stepping stones out of the traditional data center:

AISblog

Good question. And we’ve got the answer.

Here at AIS, we’ve spent hundreds of thousands of hours envisioning, designing and constructing SharePoint-based solutions for our clients. With each new version of SharePoint, we make additional investments to deeply understand the new release’s capabilities.

We’ve taken a look at all the changes and enhancements in the latest version — and you just have to look at our blog archives to realize that a LOT has changed in 2013 — and put together a short, easy-to-read whitepaper that highlights the top new features that make SharePoint 2013 a must-have for your business, including:

Smarter Search
Simpler and Mobile-Ready UI
The game-changing SharePoint App Store Model
Better Workflow
Social SharePoint
Easy Migration Tools
Lower Costs
And much more!

Please CLICK HERE to download your free copy.

Not familiar with SharePoint as a business solution? Take a look at our SharePoint solutions on our website and contact us to learn more about how SharePoint can transform your organization.

Derek Hubbard

The ability to inspect and adapt is what differentiates good software development teams from great software development teams. For agile teams, the retrospective is a key event to making that happen. Just as the daily scrum is a scheduled time each morning to plan an attack for the day, the retrospective is a scheduled time at the end of each sprint for the team to inspect how these daily attacks were executed and create an adjustment and improvement plan for the next sprint. If your team’s retrospectives have become stale and boring, or fail to generate concrete actions and experiments for the next sprint, then try some of the following adjustments. Read More…

Jason Storch

I recently completed a large document management system on SharePoint 2010 that used FAST Search and claims-based authentication. The client wanted to secure and limit access to customer-specific documents based on data coming from their CRM system.

We decided to implement a custom claim provider that would query the CRM system at login for customer claims based on the user ID. On upload (based on the customer that was assigned to the document), we used the content organizer to route the document to the correct site, library and folder based on the organization and security rules that we had. Each library had a claim for the customer assigned to it so only users with that claim could view the documents in the library. We would use search for the UI so that the users had a single place to find and view the documents. Sounds simple, right?

It should’ve been.

Unfortunately, the implementation was anything but simple. From the beginning, we hit the core limits of SharePoint 2010, FAST and Claims. Now that we’ve made it to the end, I want to talk about the limits we ran into and steps you can take in your design to avoid them. Read More…

Sam Larko

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

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

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…

Larry Katzman

SharePoint adoption is widespread in most organizations today, and a very common use case for SharePoint is as the core technology for an intranet. There are many features of SharePoint 2010 that make it an excellent choice for an intranet, including web content management, workflow, publishing and search. SharePoint offers a secure, scalable technology that empowers content owners to create, approve and publish pages in an easy-to-use, Microsoft Office-like user interface. With SharePoint, you get a great looking, high-functioning intranet that’s secure and easy to use. (In Jakob Nielsen’s “10 Best Intranets of 2013”, he notes 70% of the awardees are using SharePoint.)

With the release of SharePoint 2013, however, there are several new features that are worth noting if you’re thinking of upgrading your intranet from a previous version of SharePoint, or migrating from another product. If your organization is considering a redesign or a technology update of their intranet, SharePoint’s newest release is more compelling than ever as the platform of choice.

Applied Information Sciences Blog

Category Archives: Infrastructure Engineering

Environment and Build Notes

Integrating PowerShell With SharePoint

What is PowerShell?