Upcoming Community Tech Events in SoCal

For those of you in southern California, I've gotten wind of some upcoming events that might be of interest.  Check them out if you are in the area.

So-Cal Azure User Group - Costa Mesa, 2/24
     Register Here: http://www.meetup.com/SoCal-Microsoft-Azure-User-Group/events/220261351/

So-Cal System Center User Group - San Diego, 3/2 or Irvine 3/3
Wally's Top SCCM 2012 Features with Cool Tips and Tricks
     Register Here for March San Diego Event: https://www.eventbrite.com/e/microsoft-system-center-so-cal-user-group-msc-scug-san-diego-march-2nd-tickets-15150502561
     Register Here for March Irvine Event: https://www.eventbrite.com/e/microsoft-system-center-so-cal-user-group-msc-scug-irvine-march-3rd-tickets-15149810491

San Diego SharePoint User Group - San Diego, 3/11
Fundamentals of Creating SharePoint Apps with Tim Odell
     Register Here: http://www.meetup.com/San-Diego-SharePoint-User-Group-SanSPUG/events/219661901/

PFE Days - San Diego, 3/19
Getting the Best from Azure IaaS with Javier Dominguez
     Register Here: http://www.meetup.com/Microsoft-PFE-Days-Technology-Event-SoCal/events/220098582/

Los Angeles Big Data Users Group - Multiple Events (visit their link)

Upcoming MVA Courses

I was poking around on Microsoft Virtual Academy today and discovered a bunch of great looking live events that are coming up in the next several weeks.  If you've never checked out MVA, now is the time to visit and register!

• Feb 25th - Getting Started with PowerShell Desired State Configuration (DSC) 
• March 3rd - Azure and Open Source: What You Need to Know
• March 26th - Azure Active Directory Core Skills Jump Start

The Imperfect Lab: Check out the Microsoft Test Lab Guides

If you've been reading along for a while now, you know I've been having a blast building and expanding my Imperfect Lab. But I admit, if you are looking for a full step-by-step guide to what to actually put in you lab, I've haven't given you all that.  But I do know somewhere you can look!

Available right inside the official Azure documentation is the details (including PowerShell) for setting up a hybrid cloud environment for testing.  Now, this first guide requires you to have a physical data center lab to connect to using RRAS, but you can easily rework it for a VNET-to-VNET if that's what you desire, by following these instructions instead.

Once you have the basics in place, you can do things like build a full SharePoint Farm (on my short list), set up a Web-based LOB application or set up DirSync. Or do all of them!

Set up a SharePoint intranet farm in a hybrid cloud for testing

Set up a web-based LOB application in a hybrid cloud for testing

Set up Office 365 Directory Synchronization (DirSync) in a hybrid cloud for testing

You can find the official post about all this goodness here - http://blogs.technet.com/b/tlgs/archive/2015/01/19/new-set-of-hybrid-cloud-test-environments.aspx

The Imperfect Lab: Letting Additional Administrators Remotely Connect to Servers

An age-old server administration best practice is to make sure that everyone who is administering servers on your network are doing it with their own "admin" credentials.

Up until this point, I've done all my remote Azure sessions (PS-Session) with the built-in administrator account.  This works fine if you are only person connecting remotely to a server. But what if you want to grant others administrative rights to your machine and they would also like to connect remotely?

Your first step would likely be to add them to the local administrators group. Since you've already turned on the "remote management" feature for yourself, you might expect this to work out of the box.

But you probably overlooked this little note in the "Configure Remote Management" box when you enabled remote management - "Local Administrator accounts other than the built-in admin may not have rights to manage this computer remotely, even if remote management is enabled."

That would be your hint that some other force might be at work here.  Turns out that UAC is configured to filter out everyone except the built-in administrator for remote tasks.

A review of this TechNet information gives a little more detail:

"Local administrator accounts other than the built-in Administrator account may not have rights to manage a server remotely, even if remote management is enabled. The Remote User Account Control (UAC) LocalAccountTokenFilterPolicy registry setting must be configured to allow local accounts of the Administrators group other than the built-in administrator account to remotely manage the server."

To open up UAC to include everyone in your local Admins group for remote access, you'll need to make some registry changes.

Follow these steps to manually edit the registry:

1. Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
2. Locate and then click the following registry subkey:
3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
4. On the Edit menu, point to New, and then click DWORD Value.
5. Type LocalAccountTokenFilterPolicy for the name of the DWORD, and then press ENTER.
6. Right-click LocalAccountTokenFilterPolicy, and then click Modify.
7. In the Value data box, type 1, and then click OK.
8. Exit Registry Editor.

Now you will be able to remotely connect and administer your server using PowerShell with any account you've give Admin rights too for that particular server.  This would hold true for servers in Azure, as well as servers on your local network.

Special shout out to Bret Stateham for bringing this "remote admin road-bump" to my attention. Sometimes what looks like an "Azure" problem, is really a "Server" feature. :-)

The Imperfect Lab: Not So SharePointed

On my list of thing to try with the Imperfect Lab was deploying a SharePoint Farm from the new portal since there is this nifty wizard that just does all the work of building the servers for you.  Just a few clicks and boom, SharePoint!

But alas, it was not quite to be. While the portal does do what it claims, produces a test/dev scenario of SharePoint, it's completely isolated.  And completely isolated isn't exactly what I wanted. When you use the portal configuration "wizard" you are prompted for several bits of information that you can't get around.

1. You are prompted to give a domain name for a new FOREST domain.
2. You must create a NEW virtual network.

Because I wanted to create a little Imperfect Lab "team site" and experiment a bit with SharePoint 2013, I wanted to use my existing domain and my existing network.  But that isn't an option allowed via the portal "journey", to get what I want, I'll have to build it out the old-fashioned way, one server at a time.

Had I know this before I started this project, I might have considered creating the SharePoint farm first, then using that domain and network as the basis for the rest of my lab projects.  Oh well, that’s why we experiment in the first place right?  Live and learn. I guess I'll swing back around to this SharePoint project a bit later.

Meanwhile, if a completely isolated SharePoint playground is something you need, by all means check out the new Azure portal and give it go.  And if you need more than what the test environment provides, you might find the complete Planning for SharePoint 2013 on Azure Infrastructure Services guide useful.