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...