Exchange Virtual Conference Wrap-up #IamMEC #MSExchange

Exchange 2013

MVP Paul Cunningham of exchangeserverpro.com decided to rally some of his fellow Exchange MVP peers to produce some kickstart content for Exchange 2013 and Office 365 and create a completely free ‘Exchange Virtual Conference’.  I’ve recently finished watching all the content and I must say, this was a great idea and I hope we can see more of this type of community based content delivery in the future.  The sessions are available to anyone and archived online at the following links.

Enjoy.

Exchange Virtual Conference sessions:

0  

TechEd 2013 NOLA: Live Streams

teched2013TechEd 2013 is going on…and I’m sad.  I wish I was there.  I enjoy technical conferences.  I enjoy networking with others in my industry.  Well, some of that emptiness is going to be filled thanks to the live streams on Channel 9.

Some announcements from today include..ooh.. Windows Server 2012 R2.  R2 = bringing back the Start Button.  :)

Full list of the Streams

Keynote

0  

#PowerShell Quickie: Get-Nicbinding.ps1

I’m working on a PowerShell script to perform a Health and Config check for Exchange Server 2010 installs.  One of those checks is to verify the NIC binding order, which took me down the path of this script.  I traditionally write new scripts that run multiple processes in a modular format, just so I know that my logic is solid, and then I integrate them together.

There are a few ways to extract the NIC info, but for my usage I needed to correlate data from the Registry and from WMI.  I essentially needed to see a list of binding order similar to what you see in the GUI, the name of the NIC, and it’s current state.  Many times we have NIC’s that aren’t used for one reason or another on physical boxes and those NIC’s are placed in a disabled state.  I like to make sure they are disabled.

Note: This script has had very limited testing, I have tested on a hand full of lab machines and physical boxes.  If you find results aren’t accurate, post up a comment and let me know and I will try to address.

The next evolution of this script is to enable the user to fix anything not up to standard. For now, I will be adding an option to open Ncpa.cpl and use the GUI(ugh) to address. ;)

0  

#PowerShell and WMI to Determine OS Architecture for Automation

I’m in the process of writing some of the more complicated PowerShell code I’ve ever written to automate some laborious tasks at my new job.  The process I generally like to take when writing something like this is to modularize parts/steps of the automation as standalone components to be reused and consumed elsewhere.

Part of what I’m automating requires running installation of software.  This software comes in 32-bit and 64-bit flavors, so picking the correct install bits is very important.  In searching for “the best” way to determine installed OS Architecture, it became very apparent that Admins out there were relying on, what I would characterize as, error prone methods.  I needed something that would work on Windows Server 2003, 2008, 2008 R2.  Yes I’m aware that 2008 R2 is x64 only, that makes things easier, but I need to have a streamlined and solid method of checking, regardless of what system is running the install task.

Starting with the Vista/Server 2008 , a new property was introduced to the win32_OperatingSystem class, called OSArchitecture which makes this relatively trivial.  However, I want something that will work on 2003 if needed.

I started looking at other WMI classes to find a reliable way to determine, without having to rely on parsing text strings of a Caption property or other various methods.  I ended up finding the win32_Processor class and found a quick and easy solution – the AddressWidth and/or Architecture properties.  The Architecture property would be ideal if looking for Architectures other than 32/64-bit.

Below is the extremely simple snippet to perform this check against the first and sometimes *only* CPU installed. I know I had very limited reliable information out there on this, so I hope this helps someone in the future.

0  

So I Resigned From My Pretty Awesome Job.

On Friday 3/4, I resigned from my current job as IT Systems Architect/Team Lead for our Systems and Messaging group. It was one of the more difficult decisions I’ve made in my ~12 year IT career. It’s hard to leave a company who has treated you well. In 4.5 years with them, I’ve been promoted twice, given additional responsibilities, and selected for unique and challenging projects. Weighing this decision literally took a physical toll on me while I hashed it out and waited to provide my resignation. I’ve accomplished a lot and have much to be proud of and hope to continue that success on my future projects. Looking forward…. I’m heading to a Cloud! Service provider and will be on their Exchange Team, implementing and supporting both shared and dedicated platforms including their mobility offerings. This in itself is exciting as I’ve been working with MS Mail/Exchange since I started in IT. I also hope to help this company productize Lync Server 2010 as well. I’m excited as this new role will force me to obtain those certifications I wanted to pursue in 2011. Oh yeah, my new job is 100% work from home. I’m pretty excited about that too.

I get to meet my new team in a next week.

0  

#Exchange 2007ActiveSync: Control Which Users Are Enabled…Automagically

Last year when we launched support for Windows Mobile 6.x devices via Exchange ActiveSync, I had a challenge of making sure only approved users were enabled for ActiveSync support. By default in Exchange(all versions), all mailboxes are enabled for ActiveSync, and specifically with Exchange 2007 when the CAS role is installed into the Organization. I decided to write this quick script to fix this ‘feature’ and would allow me to run interactively or via the task scheduler.

Prerequisites:

  1. Create a Universal security group
  2. From the EMS, get the GUID for the newly created group

    I wanted to use the GUID to prevent the script from breaking in the event someone changed the group name.

You will need to populate the $grpguid variable with the GUID you obtain from Prerequisite #2. Once complete, schedule to run on a machine that has the Exchange cmdlets and you will be off and running.  Once you want to control who is enabled, simply populate the group  that you created in Prerequisite #1 with users who’ve been approved to utilize ActiveSync.

Feel free to leave any questions in the comments.

0