Easy way to move iTunes library location...make it Virtual!

So, iTunes is a pain in the butt sometimes.  It really doesn't like your library being on a network share as it gets very sluggish and breaks the software if you change the "location" that the Music folder points to.

I happen to have a decently large iTunes library at ~150GB in size (lots of audiobooks and movies, etc).  This can be cumbersome to move around and manage and it also will not comfortably fit on my shiny new 256GB SSD in my desktop.  I also happen to have a 1TB drive in my desktop for just such an occasion.

I've found the best way to manage this is using symbolic links (symlink).  A good guide on creating symlinks is here. A symlink is very useful because it acts like a pointer on disk to another folder.  Obviously everyone is familiar with a Windows Shortcut...which is a hokey/fake pointer...its a file with an address to another file that you have to click on, etc.  It's like some guying telling you he knows a guy and here's his home address on a napkin.

A symlink, on the other hand, is a true legit pointer that even "tricks" the operating system into working correctly.  Its like a magic door that if you step thru it you're magically in another place...like the wardrobe of "Lion, Witch and the Wardrobe" fame.

So if you make the "Music" folder in your profile, which iTunes (and most other things) use by default, a symlink, no apps, or even the OS, really knows that the files are somewhere else. (Obviously the OS would know if you ask it specifically, but otherwise it plays along with you like a good friend should).

1. Close iTunes.
2. Move the iTunes directory to where you want it to finally live.  In my case it was D:\Cloudstation\Music.
3. Delete the default Music folder (usually located at C:\Users\<username>\Music.
4. Open a command line with administrative privileges.
5. Change to your user directory (C:\Users\<username>)
6. Use this command  "symlink /D Music D:\CloudStation\Music".
7. Voila, now your My Music pointer in your profile points to the D: drive.

If you now open iTunes, it should open up none the wiser that it is now running from another physical location because the path that it uses (C:\Users\<username>\Music\iTunes) is still valid (symlink!).

This still works if you wanted to move iTunes again to another location.  Just delete and recreate the symlink after moving the files!

Enjoy.

How to setup Sophos/Astaro Web Filtering to use AD Single SignOn

How to setup Sophos/Astaro Web Filtering to use Active Directory Single Sign On

So very recently, I had a customer that wanted to block Internet usage for the users, but obviously still wanted the execs to be able to go to more sites (like finance sites, etc).  This customer is using an Sophtaro firewall (Astaro now owned by Sophos...thought that sounded better then Assphos) that I sold to them and manage.  There doesn't seem to be a lot of great documentation on how to do this, but I figured it out with a combination of built-in help files as well as the sparse online docs. 

What I'm trying to accomplish is that the client will authenticate to the firewall using their Active Directory (AD) username and password, the Sophtaro will check it against AD and depending on what AD group their in, it will apply a specific Web Filtering profile to them for less restricted browsing.

This can be done with either the standard web proxy and/or proxy profiles as needed.  In this environment, I use the default proxy in transparent mode (so that will catch web traffic for all machines on the network) and then have a separate proxy profile just for the executives.

Note: I could have gotten the same results by setting static IPs on the exec's machines, but static IPs are bad on desktops unless absolutely needed.  SSO is more elegant and flexible.

The rough steps are:

1. Add the SSO source
2. Add the Astaro to the AD domain
3. Create the AD group with correct users in it.
4. Create the Astaro group that references the AD group.
5. Configure the Web Security settings and/or setup the proxy profile using the Astaro/AD group.
6. Configure the client(s) to point to the proxy server on port 8080.

The detailed steps are decently well-defined by this Sophos support article.  I say decently only because the article seems to have been edited a few times and the language is occasionally "broken".

Make sure that all machines can resolve the hostname of the Sophtaro firewall.  This is the hostname defined under Management -> System Settings -> Hostname. It is crucial for SSO usage that it be exactly this hostname and not the IP address or some other FQDN..  Check out my other blog entry on how to do this simply:  How to setup public DNS record overrides on Astaro/Sophos firewall.

Now in my case, I wanted the Execs to have less restriction (so only a few users/machines) and everything ELSE to have more restriction (and later to even have a full block profile for kiosks and what not).  The way I accomplished this was to setup a Proxy Profile for Execs using the SSO functionality, but then left the default Web Filter on Transparent mode for the whole network.  This means that every other user/device will be more restricted, but the Execs will be authenticated against the profile for increased access.

I hope this helps and good luck.

Brendon

How to setup public DNS record overrides on Astaro/Sophos firewall.

There has been some debate both inside and outside of Microsoft if it is better to have your internal Active Directory domain match or be valid as your external or public domain (e.g Microsoft.com as the AD domain as well as their public presence).

Now I have customers that are setup both ways for different reasons.  In many ways, I prefer the ".local" domain internally because then public websites, etc are managed on public DNS only.  This would be especially true if you host your Public DNS (which I strongly suggest companies not do), but even then it can be managed.  Overall my point is that it is cleaner and simpler to have private.local and public.com separate.

Unfortunately, by having a disjointed namespace, sometimes you will want clients to be redirected back internally when using an external URL...most commonly for Exchange services (Outlook Anywhere, OWA, ActiveSync) though there are other times, such as using SSO on your firewall.

Now, there are many ways to accomplish this re-routing using NAT rules on a router/firewall or hosting a stub zone on private DNS, etc.  The simplest way I've devised is to use the firewall as my DNS forwarder and setup the static entries there.

Here's how it works (we'll use Exchange as an example):

1. Clients need to resolve email.publicdomain.com which is hosted internally.
2. Clients obviously point to internal DNS servers (usually AD servers, but not necessarily) looking for email.publicdomain.com, but they don't host that domain; only email.private.local.
3. Those private DNS servers use the Sophtaro firewall as their "forwarder" (could also read as: next DNS hop) and pass the request onto to the firewall.
4. The Sophtaro has static entries setup for email.publicdomain.com that point to the internal IP address of the Exchange server (or whatever application needed) and passes that back to the AD server which passes back to the client (that's not EXACTLY how it works, but close enough).
5. The client can now use the public URL of https://email.publicdomain.com in their Outlook and iPhones to access the Exchange server whether they're at home or on wireless in or outside of the office (i.e. everywhere) and the URL will always work.

These static entries are created on the Astaro firewall by going Network Services -> DNS -> Static Entries. Most people might not think to use the function this was as usually you have to manage a full domain in DNS.  Fortunately, the Astaro allows you to treat it almost like a local hosts file for the network.

Good Luck.

Exchange 2013 Cluster - Part 3 - Setup 2012 Active Directory

Exchange 2013 Cluster - Part 3 - Setup 2012 Active Directory

So, in order to have Exchange, you have to have Active Directory, at least since Exchange 2000.  In times past, in order to install AD, you would run dcpromo on the server (usually after adding to the domain) and after a few deceivingly simple questions, an AD DC server you would have. Voila.

Now to install AD, there's more steps to fit into the new "role and feature" paradigm.

1. Run the Add Roles and Features wizard.
   
2. Choose next, next, next to get to where you can choose "Active Directory Domain Services".
3. You will get a prompt about installing additional related features like this.  Click Add Features.

4. After that, you're Role selection screen should look like this. Click Next.

5. On the Features selection page, you'll notice Group Policy Management is already selected.
6. Click next, next, Install.
7. Once that finishes, in the top right of Server Manager, there will be a flag with an exclamation sign and if you click on it you will see the following. Click the link to Promote this server...

8. After that the wizard will prompt you what kind of DC you want, in my case for a test domain, I will be creating a new Forest and will chose such option and click Next.

9. Some checks will be performed in DNS and NetBIOS to make sure this domain doesn't already exist anywhere THAT THIS MACHINE CAN FIND. 
1. NOTE: this doesn't mean it doesn't exist anywhere but because of the current DNS settings and network location, it can't find it anywhere else.  Remember NetBIOS has broadcast ability.
10. On the next screen, choose the functional level and DC capabilities and enter the DS Restore password.
1. There's usually not (read: never) much reason to uncheck DNS or GC...its really the only way to make sure all DC's are created equal (aside from FSMO roles which are malleable....word of the day!!!).
11. After you click next, you'll get some nonsense about can't create a delegation, but that's because in my case (as in most cases) you don't control the ROOT dns servers (e.g .com)! Just click Next.
1. This would not be true (I believe) in the case of making a subdomain such as  sub.domain.com. In this case, the install could contact the owner of domain.com and setup a delegation.  Note: I could be wrong on that whole last sentence, but I'm confident.
12. NetBIOS will broadcast to make sure this domain doesn't already exist anywhere THAT THIS MACHINE CAN FIND.  Confirm the desired NetBIOS name and click Next.
13. I generally leave the default file paths (you may not do this in production depending on the (expected) size of your AD. Next.
14. Now you will get a lovely summary screen of all those life choices you just made.

15. Make note of the View Script button (circled in red) which will show you the glorious power of Powershell to do everything the last 8 steps did. Click Next.
1. In my case it looks like...
1. Import-Module ADDSDeployment Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "Win2012" -DomainName "test.com" -DomainNetbiosName "TEST" -ForestMode "Win2012" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true
16. Checks will be run, security warnings will be ignored and INSTALL!
17. After running the install, the server will reboot and you are DONE!!.
18. Now go fix the DNS settings and so the Internet will still work.

Special Note: If you'd like to use PowerShell to do ALL OF THE ABOVE...use this Scripting Guy TechNet Blog article.

Next:  Part 4 - Exchange install in the Main Site.

Exchange 2013 cluster - From the Ground Up - Series Intro

Hello Everyone,
Its been a while since my last post, but I was busy with holidays and then working on a fairly demanding customer project; a Novell to Microsoft migration - directory, file and even email...more about that some other time.

What I want to do is a series of posts about building up an Exchange 2013 cluster from the ground up.  It will consist of the following:

• Main Site - 2 Mailbox server and 2 CAS servers.
• Remote site - 1 (Mailbox + CAS) server.
• 1 or 2 DAG's.

Since this isn't my production environment and I actually have a full registered test domain, I can use much lower hardware (in my case virtual) specifications than a "real" environment would, but this is meant as a learning exercise as an Exchange consultant (among other things).  NOTE: this is not meant to be a full description of how 2013 works, but obviously certain parts and changes will be touched on.

NEXT: Go over hardware specs and build servers...

VC, SUS, vNet, VLANs and a partridge...

So, recently I've been doing a lot of research on Virtual Connect, primarily because I've recently purchased some!

I've bought the following:

1.  HP c3000 BladeSystem chassis
2. 2 x HP 1/10GB Virtual Connect Ethernet modules
3. 2 x Cisco 3020 Blade switches (wouldn't SwitchBlades sound cooler?!) for mezz 2 for storage connectivity (ISCSI/NFS).
4. 8 x bl460c G1 blades for ESX and Hyper-V hosts...and maybe some other nonsense.

This will happily replace my 7!!! DL360G5's and use less power, produce less heat and make less noise...well maybe not the last.  BUT it will do the first 2 which saves money!

On to the point of this post...

In trying to understand the joys of Virtual Connect magic, I acquired the HP Virtual Connect Ethernet Cookbook which can also be found here (along with other supposedly useful bits).

After reading thru this and analyzing the differences in the scenarios I've come up with these differences and explanations:

Virtual Connect

Its like a switch with its legs cut off...but it feels like a bridge except it has more then an in and out port, but maybe not really if you consider you setup virtual connections inside it from each blade out to the external net...so maybe many bridges virtually layered? Or just a switch that looks like a single contact point to an upstream switch (no spanning tree).  Or maybe it's a switch that won't participate in a Spanning Tree.  Bottom-line...its Virtual Connect!

vNet vs SUS

This was the harder one and really the juice of the VC for me to understand how to pass VLANs. Here's my simplest explanation.

• vNet = Check a box to Tunnel VLAN traffic and it will pass all traffic as it is received...it dumbly hands it from one interface to the other never looking inside the envelope.
• SUS = Is all nosey and analyzes VLAN traffic and is told whether Adam's Left hand (Blade A, onboard NIC 1) is allowed to see all the VLANs or only VLAN 0 or 101 or 0 AND 101-104; or his Right hand (Onboard NIC 2) can see this versus that.  And then Brenda's Left hand (Blade B port 0) can see this or that, etc.  Ok, that wasn't simple.  Basically, with SUS, you can determine exactly what VLANs (including 0) are mapped to exactly which blade ports (if not ALL or NONE).

So really SUS allows you much more granularity on your traffic...if you want it.

So for all those Virtual Connect experts out there...I invite more in depth or probably more accurate explanations  as I couldn't really find just that...vNet vs SUS for dummies.

Enjoy.

vCenter 5.1.0a: Rollercoasters and you

Hello,
So for the past week(!), I've been trying to get vCenter 5.1.0a installed for a certain environment and it has been an experience!

*NOTE FOR ANYONE NOT INTERESTED IN READING:  I want to give credit to a series of posts by Derek Seaman that I ended up using for reference.  They didn't end up solving (or having anything to do with) the problems experienced below, but they are well written and informative and I will refer to them in the future for a vCenter install.

For full disclosure, I did go in pretty blind.  I figured, I've been doing this for a while and pretty familiar with vcenter, lets just get the ISO going and see how it smells.  Well, when I saw multiple addons/prereq's, I realized it was a new beast.  Bear in mind, the current one is only 5.0 which was still the more traditional install.

At first, I tried to upgrade the current vCenter (running as a VM) and that blew up for some reason that I don't recall.  When I looked at the programs list though, there was a bunch of older version software (thanks for keeping 4.0, 4.1, 5.0 versions of the client installed) and honestly, that VM always felt a bit sluggish and the vcenter service would commonly not start.  So, I decided to move it to a different datastore and shut it down.

Before shutting it down, I deployed a new 2008 R2 vm from my template which I've used on many other machines. I took a snapshot of the vm at each stage while installing and was very methodical on installing the 3 different, check...4 different aspects to a modern vCenter install.

1. Single Sign-On
2. Inventory Service
3. vCenter
4. Web Client (supposedly optional, but required for 5.1 (and beyond) features...)
1. Check out my other post on this subject

Moving on, after installing the first 2 without a hitch, vCenter would NOT install.  I kept getting this...

and then this...

 

So I when hitting up Giggle for the problem, I found a link saying to give the Network Service permissions on the C:\ drive and that would fix it. Admittedly, this did reference older 4.0 or 4.1 installs, but was my exact error # 28038.  Now, I don't know if you know this, but it is not trivial to modify the permissions on C:\Program Files, c:\Program Files (x86) or c:\Windows in 2008 R2...meaning it won't let you.  Specifically Administrators has special permissions set and "Change Permission" is not one of them; obviously neither is Full Control.  Based on that and considering the web wasn't blowing up about 5.1 on 2008 R2, I theorized this wasn't my answer.

The other suggestions were around "making sure its not a domain controller" and "remove the ADAM or AD LDS role" which neither was installed of course.  I kept seeing references to IPv6 for name resolution, but I've used DNS once or twice in my time, so that wasn't the problem (yes I did triple check all resolution directions just to make sure).  IPv4 worked fine, but so did IPv6; if you just ping the name on a 2008R2 server, often you will get a reply from the IPv6 addreess.

Another thing was that my template was fully patched as of 6/10/2012 or something, but in the Programs list, it had Visual 2008 or 2005 redistributable patches as well as Silverlight.  I couldn't imagine how any of that was screwing this, but I uninstalled them anyway, but that didn't fix the install.

So...I was stumped and it was 2am.  I had 2 choices...completely registry-disable IPv6 and/or completely rebuild.  I of course was tired of screwing around and rebuilt.  Again very methodical...snapshots at each stage.  I didn't even patch the server...just install os, install vmware tools, configure IP, add to domain, and then start vcenter install. 

This time I chose the simple install considering I was doing just that.  Guess what...worked no problem including the web client install (which previoulsy had not worked due to some other variable I can't remember)! I suspect that either a patch was getting in the way or one of the pre-setup bits I had done on the template had somehow screwed it up.

So, sometimes punting really is the best and only choice.

Go Pats!

Again, for anyone looking for a very descriptive walkthrough of a 5.1 vCenter install, please reference Derek Seaman's 796000 step process to installing vCenter 5.1.0a! (its really only 13).

NEW!!! WEBIFIED vCENTER! Get your's now!

Soooo...VMWare has decided to scrap the "thick destkop client" and go to a web-based front end. 5.1 is apparently the last version that will "support" the desktop client and even now, the new features for 5.1, such as hardware version 9, are only available thru the web interface...so its required now.

I'm always fearful when a company tries to force a web frontend, but sometimes (often times?) they turn out ok. Many firewalls are web (personal favorite Astaro/Sophos has a very good web frontend), many NAS boxes are web, even enterprise storage like Nexenta is web, but VMWare Infrastructure (classic name) is a pretty complex product doing alot of things, so I hope they do it right and make it perform and not cumbersome to use. The desktop client was pretty durn good....

Also, a little birdie told me that this and the VCSA (Virtual Center Server Appliance) are coming from a desire at VMWare to be non-dependant on Microsoft to run their product (I'm cleaning up the language a bit on their behalf).  Now of course I can't fault them and appreciate simplicity, but it still needs to be usable.  Oracle as a backend (for more than 5 hosts) is certainly not what I would call "common" even in medium size companies so is that really the best choice? Plus as far as companies go, can anyone really argue that Oracle is somehow "better" than Microsoft?

I'm predicting the future of vCenter will ONLY be the VCSA (I guess they'll have to incorporate VUM somehow), but don't see Oracle-as-the-only choice being viable.

Good luck VMWare and I hope it turns out well.

Setting up VLAN's...finally!

So, yesterday, or most accurately, very early this morning, I finally figured out how to setup VLANs in my lab.  While I know VLANs are "the shizz" and have long understood them conceptually and have implemented elsewhere, I hadn't yet done so in my special bag of goodness.  Plus on top of that, I've just replaced my core network switches which made it both easier and "harder".

So, to review, the lab environment (above) is a Sophos (formerly Astaro) firewall, now connected to two D-Link DGS-1248T 48 port smart gigabit switches.  FYI, these switches are now end-of-life, but they still work so no harm, no foul.  Connected to those are my ESX hosts. Magical, right?  Previously, I was using a Cisco 4506 blade switch, which was very nice and "a proud banner of Cisco" in my lab, but it also used 500+ watts of power alone and is huge.  I will cover the pros & cons of why the DLink's over 4506 in another post.

Set VLAN in ESX

So many others have documented how to setup VLANs in ESX, but I will review quickly.  There are three ways to provision VLANs in ESX.

1. Set the VLAN on the virtual machine Port Group on the Virtual Switch.

2. Set the port group VLAN to 4095 which is a passthru, and set the VLAN inside the VM (like a physical / traditional server).
3. Set the VLAN ID inside the physical switch the ESX host and specific uplink port is connected to.  Drawback here is that the VLAN would only be respected outside the ESX host; internal to the hypervisor boundary there is only the port group limitation which acts very similar to a VLAN anyway.

Of the 3, option 1, is preferred as it is the most obvious (to setup and to "discover"/remember after the fact), the most straightforward as you don't have to customize the VMs at all and the most dynamic and mobile.

Set VLAN in Astaro/Sophos

*This article is based on Sophos UTM 8.306
For those of you not familiar, the Sophos UTM firewall (formerly Astaro) is what I would call a "packaged linux firewall".  While it isn't some highly customized or proprietary kernel as far as I know (corrections?), it is a very slick interface for a fantastic collection of network "utilities" including Web proxy, firewall, smtp filter, VPN endpoint, DNS, DHCP, etc.  Hell it even runs an NTP server.  While I'm sure many other firewalls do all this and maybe more, I very much like the interface.  Please do check out their website and they even offer a free-for-home-use license which is very feature-rich.

A standard "plug in cable from switch" interface is known as Ethernet Standard and this takes ownership of the physical network port/device. To configure an interface for VLAN, you actually create (or switch to) an Ethernet VLAN "virtual" interface and attach it to a physical interface.  You can not have a Standard and a VLAN interface on the same physical port, but you can have multiple VLAN interfaces sharing the same physical port.

Set VLAN on switch ports

The D-Link DGS-1248T, as I said, is now end-of-life, but most switches in this category, 1U, Smart / Web-managed, etc are pretty similar.  D-Link, Netgear, Trendnet, Cisco (repackaged Linksys) all have switches in this category...they work.  Since this unit is older, it only supports static Trunking vs LACP and only 6 LAGs (Link Aggregation Group) using up to 8 ports each, but it does have 9220 jumbo frames and 802.1Q VLAN support, so for my small purposes, it works quite well.

To set up the VLAN on one of these switches you have to:

1. enable Asymmetric VLANs
2. create the VID = VLAN ID(?)
3. configure one or more ports for the VLAN as either Tagged, Untagged or Not Member.

The (un)tagged nomenclature is a little confusing and I'm not the only one as evidenced by the amount of forum posts about this exact topic.  The most simple explanation I found for "tagged, untagged and non-member" came from here.  Short version: the title (tagged, untagged) describes the state of the packets coming in to the firewall.  So, if ESX is already assigning/labeling/tagging that port group traffic as VLAN 1002 then you would mark either that incoming port on the switch or in my case for simplicity, all ports, as Tagged; that way, the switch won't modify the packets at all and will pass them along correctly.

As you can see, I have multiple VLANs configured and available on all switch ports.  In my simplified case (as with most small/med businesses), there is no downside to having all VLANs available everywhere.  In larger environments, especially Cisco, you have to worry about Spanning Tree Protocol across the switch fabric as more VLANs equals more overhead, etc and becomes cumbersome to manage.  Be aware.

One thing to note, if your connecting one switch to another in this fashion and you want to maintain the VLAN info (why wouldn't you?), the uplink ports must be "tagged" for each VLAN regardless of the tag state of the incoming traffic.  By tagging the port, the switches maintain that VLAN id and don't drop it.

Summary

So as you can see, you have to configure the VLAN info almost everywhere...the cables are safe at least!  Once you do it the first time, its pretty easy after that.  The easiest way to test if it is working...PING.  Either ping will work or it won't if the VLAN is correct or not.  In my case, I was pinging from a guest VM on my RT VM port group to the firewall. Until I had it all correct, ping no worky!

Good luck and K.I.S.S.