Monday, April 6, 2009

Powershell in WinPE

Sorry for not having posted in a while.

1.  Powershell in WinPE would be so freaking amazing.  I know it's because the .NET framework is not in WinPE, but PLEASE give me PoSh in the next version!!

2.  I have a new blog to consume the digital signage content, and that's where I've been.  http://mblog.lib.umich.edu/digitalsigns

More to come soon!


Monday, February 9, 2009

Educause 2009 Proposal

For your review. I hope to do a talk at Educause in November about what we're learning by leading this digital signage initiative. Here's the proposal.

Distributed innovation in the decentralized institution
Abstract

The execution of an innovative, distributed project in a historically decentralized institution provides powerful lessons and frameworks for future efforts. An interdisciplinary group from a number of University of Michigan colleges collaborate to build a shared Interactive Digital Signage infrastructure for the use of the broader University community.

1. Every enterprise needs to distribute information to its community. This has traditionally been accomplished with bulletin boards and posters, and more recently with PowerPoint or similar products, broadcast via public monitors. An industry around improved solutions to this problem has developed within the last decade, providing sophisticated systems that promise rich mapping and wayfinding interactivity, granular management, and polished designs which far surpass the abilities of PowerPoint or Keynote-based presentation solutions for public spaces.

With these new opportunities to modernize available channels of communication, to provide the ability to easily distribute emergency notifications, and to generally enhance the user experience of their communities and visitors, a number of University of Michigan departments were independently investigating the purchase of new digital signage systems or the replacement of obsolete systems in 2007.

At the School of Dentistry, as this discussion comingled with an institutional initiative around the “spirit of the IT commons,” it became clear that a joint solution could provide great benefit over siloed solutions; notably, significant reduction of TCO, eased deployment of emergency notifications, and the development of much-neglected interdisciplinary strategic alliances.

The alternative seemed to be the installation of multiple non-interoperable systems, requiring significant duplication of work – for example, the provisioning of multiple server infrastructures and the development of separate sets of content. This would also eliminate opportunities for the community to share content, design, branding, user experience, and messaging. Some units would surely implement interactivity and wayfinding while some would not; deployed interfaces would differ and end-users could become confused or frustrated.

2. Description of activity, project, or solution:

In the closing months of 2007, this vision of seamless interoperability and a single shared signage/”interactive wayfinding” infrastructure motivated us to evangelize the University community about these possibilities.

After members of the Dental Informatics group expressed their desire to assume leadership of this initiative, and had received understanding and support from their chain of command including the Deans, we conducted both informal and formal presentations to campus IT leadership groups to encourage collaboration.

Initial investigation revealed that the market for signage solutions was saturated, with over 300 companies offering broadly varied products. A targeted RFI produced over 40 responses, and this field was narrowed to less than 10 solutions as we refined our requirements. Additional presentations for the benefit of campus IT leadership were conducted, and these presentations were followed by a “trade show” event displaying a cross-section of the available solutions.

Three finalist suppliers then presented on-site demonstrations of their products, and a contract was awarded for a pilot in August of 2008.

Following a word-of-mouth and e-mail campaign soliciting interested parties, the conversation on campus crescendoed quickly and the pilot grew in scope, almost to the point of being unwieldy. Many – perhaps most – campus units expressed interest in participating. Some units set aside nascent searches for signage solutions and agreed to follow the campus direction, electing to wait for the pilot to conclude. The pilot was closed as the set of interested groups grew larger than the pilot scope could absorb.

After presenting the vision, the RFP, and evidence of this campuswide collaboration to the campus stewards of centrally-managed IT initiatives as well as the office of the Provost, the project was generously subsidized. This funding made it possible to realize the project with fewer roadblocks than would have been encountered otherwise.

3. At the time of this writing, we have reached the following milestones and outcomes. A follow-up presentation at Educause 2010 will describe outcomes and lessons learned from the transition from the pilot phase into campus-wide production as well as the build-out of the network.

a. Provided a pride point and PR opportunity for the originating units, who took the lead in facilitating the easy implementation of this complex system by the campus community.

b. Successfully organized the purchase and installation of software infrastructure powering 87 new digital signage displays (30 interactive and 57 non-interactive) within 9 buildings, fulfilling the pilot scope.

c. With diligent communication efforts, both face-to-face and electronic, as well as freely-distributed documentation, the group received support and plans for future participation from a majority of the remaining “non-pilot” units on campus.

d. Trained users from all units in the use of the system before its deployment in order to establish campus-wide buy-in and commitment to the shared infrastructure.

e. Worked through a negative situation with a graphic design firm for UX design, finally terminating that relationship and taking on the responsibility for UX design within the project team, who provisioned an innovative GUI for wayfinding, directory search, and communication.

f. Architected a sophisticated emergency notification mechanism which makes deployment extremely simple for non-technical users at Public Safety.

g. Developed policies and guides as well as a glidepath for other units implementing the system during and after the transition to the post-pilot, site-licensed implementation.

h. Provided precedent for central support of future collaborative/distributed efforts with mutual benefit across campus.

4. Besides the practical lessons learned through discovery, deployment, content development, and installation, broader lessons regarding interdisciplinary cooperation and distributed innovation have developed. The processes underlying the development of this pilot and the development of the community around the system can be applied to distributed projects in any enterprise.

a. Substantial cost savings and reduction in system TCO (for this project, we conservatively estimate savings of $1M) are achieved by sharing a single infrastructure and distributing project startup labor.

b. Interdisciplinary communication and relationship-building provide synergic benefits beyond the scope of the project at hand.

c. Adherence to a consistent, internalized mission as well as a vision for success whose goal is the benefit of the whole of the enterprise results in positive outcomes which are greater than the sum of their parts.

Wednesday, February 4, 2009

The Long View: Desktop Management

With a billion virtualization and cloud solutions in the marketplace right now, developing a cogent long-term desktop management strategy is proving to be a challenge.  We have a lot of specialized equipment in the research areas of the organization, including a few Windows 98 computers that we can't decommission; a hundred task-oriented workers that could easily move to Terminal Services; a couple hundred "power users" that need some horsepower at the desktop for digital imaging and radiography; a couple hundred clinic machines whose loadsets and roles in the practice are still developing rapidly.  With this kind of diversity in the enterprise, having a simple and sustainable support and management model isn't easy.

If it weren't for the recent push to reduce power consumption and costs as much as possible, it would be tempting to expand our single-loadset, group policy-based model to the entire enterprise.  This would maximize the amount of cycles at the user's desktop, but also maximizes  the amount of support necessary for all that hardware.

On the other hand, moving all the desktops to the datacenter using Terminal Services (I guess it's renamed Remote Desktop Services now) isn't practical because of all of our faculty, research, and clinical special needs, so we're stuck with a hybrid solution; necessitating two support models and extra complexity.  In general, the sysadmins manage and troubleshoot the thin clients and TS farm, and the desktop support guys manage the fat clients.  

Michael Greene (Microsoft higher-ed and virtualization guy) confirmed my hunch during a recent conference call (that I'd scheduled hoping that he would have an obvious solution at the ready, which was a ridiculous expectation in hindsight) - the hype is certainly around moving the desktop cycles to the datacenter and the disk to the cloud, but the technology isn't fully baked yet, and besides, it's not for everyone.  Additionally, the super-new hype is around the smartphone/mobile device replacing the desktop machine relatively soon.

After all this, I don't feel like we've made much progress toward a workable 5-year plan in this space.  Therefore our current solution looks like:
  • Upgrade the TS farm to 2008; maybe add as many users as we can and decommission their desktops
  • Keep imaging and replacing special purpose and power-user desktops according to replacement schedule
  • Refine the GP-based UX provisioning that we have in place
  • Continue to use a single WIM loadset across all of our fat clients
  • Continue to waste lots of power and desktop support man-hours
To paraphrase every infomercial ever, "there's got to be a better way!"
 

6434 Day 3

Final day of the Powershell course, and I'm thoroughly not impressed. A lot of the labs are set for 60-75 minutes and they're literally 10-15 minute exercises. Also, as nice as the instructor is, he doesn't engage the class during the lab exercises or walk around to see how people are doing. I know he's not obligated to do that, but it would be nice to kind of ensure that everyone's actually on the same page. As it is now, a lot of the attendees aren't even paying attention.

The intro to WMI (Module 8) isn't bad, but the book doesn't go into enough depth on the syntax for there to be much to take away for the novice other than a few specific cases. If you don't understand WHY a command works, there's not too much utility in remembering it. This is the great strength of the Payette book. I really feel like I get how the gears mesh in there now, and that's totally invaluable. If I were MS Learning, I'd design a PS course that dug deep into syntax and construction, maybe covering less ground but covering it much more thoroughly.

Module 9 is around managing AD. The first lesson is about transferring FSMO roles, not something you'd generally do every day. Kind of odd. Second lesson: raising domain functional level from PS. "You only do this once..." - maybe, then, not an ideal opportunity to use the shell or a scripting language.

Funny:

PS> $dc = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
PS> $dc.OSVersion
Windows Serverr (sic) 2008 Enterprise

Tuesday, February 3, 2009

6434 Day 2

Module 5: Intro to scripting. I missed this because of meetings.

Module 6: Comparison operators, leading into flow control.

The start-demo function isn't working and didn't work yesterday. Looks like the instructor hasn't loaded it. He's copying and pasting the demo code into a PS console. Sort of surprising he wasn't provided instructions on how to get that to work.

If/else vs. Switch. VBScripters are piping up - "this is just like Select Case."

Foreach; instructor is creating a false distinction between foreach and foreach-object. The curriculum gives two different ways to accomplish the same thing, but it's not made clear that these are two routes to the same place.

Ha! One of the demo scripts has a big "TO DO!!!" in it, doesn't look like they ever finished writing this piece of the curriculum.

Filters vs. Functions. "Functions process all input at once, filters process each input object individually." "A function with a begin, process, or end block is actually a filter."

Using parameters -

function test1 ($first, $second) { "first=$first"; "second=$second" }

He's managing to confuse me here and I already get this. Overcomplicating the explanation is not helping. This might not be the case, but I'm getting the impression that this course isn't completely baked and the instructor might be able to use a little more practice.

Lab exercise: We were asked to write a script that takes one parameter (computer name) and retrieves win32_operatingsystem. Use a switch to output the friendly name of the build number. Pretty good exercise, I can see the rest of the class banging away on it.

Vital note: I keep thinking about "How Is Babby Formed." It made me laugh out loud on the bus this morning.

Providers and psdrives. Wildcards, pattern matching, and regexes. For a beginner I bet this is whizzing by too fast. This could potentially be a 5-day course with a little bit more comfortable pace. Unfortunately, since the time I signed up for this course I've become a lot more proficient with PS, so a lot of this is review. It is good to get some specific lab assignments to work on, though. I find I still need to look things up occasionally, so I'm certainly learning stuff. But it doesn't really feel like it.

Still no mention - even a hint - of V2.

Done for the day. Time to head home and chop on a commission piece, a backing tracks-only cover of a nice little 3/4 ballad. I love not being responsible for the vocal.

Monday, February 2, 2009

Music for Films

Worked for a few hours today scoring a couple shorts for Whitepeople.TV.  These are some of their best work and I can't wait to be able to share them - three short parodies of famous scenes from Matt Damon movies.  The underlying joke isn't exactly subtle but they're well-made pieces and I'm happy with the way the music is coming along.

Recording location audio for film must be harder than it seems, though, because almost every piece I work on has a crazy noise floor that's sometimes almost louder than the actors.  I rolled off the voice track at 200 Hz and that helped, but there's still a terrible hum.

Custom Helpdesk AD Console!

I've tried no less than three times over the course of my career to create a custom MMC implementation for the help desk fellows.  Admittedly, I haven't tried hard, but I've spent a few hours here and there, first with the "taskpad" functionality within the MMC itself, and most recently with PrimalForms.

Today I was encouraged to see that Dmitry from Quest had written about this very capability in the interest of soliciting beta testers for PowerGUI 1.7.  He described in his post just about exactly what I'd been trying unsuccessfully to accomplish, so I hit Darin Pendergraft up this afternoon to express my interest.  After one round of e-mails describing my dream for a custom locked-down Powershell-based console for the helpdesk, and after about 15 minutes, Dmitry had something mocked up that looked just like what I wanted.

I guess the point(s) is (are) that a) Quest is great, and b) PowerGUI is pretty cool, and c) it never hurts to ask.

I hope to either get something close to this from Quest.  If I'm misunderstanding and they're not actually planning to give this to us out of the kindness of their hearts, I'll set about trying to build it myself.  Either way, I'll report back here and share.