SBS is going! A sign of the future?

27 08 2012

The recent news that Microsoft are discontinuing their all-in-one Small Business Server (SBS) offering sent a shockwave through the entire IT community. In a blog post on the SBS product group’s blog at the start of July, the news was made very clear: the end of an era is upon us. However, it is not just small businesses or those who specialise in working with them who should listen up and take note. This development is one of many which will define lasting change in the way we do computing, in this decade and beyond.

For those who are not in the Microsoft or the SMB market, SBS rapidly became a valuable product for companies with 75 users or fewer when it was introduced to the market. The platform was an instant winner because it combined a good number of products from the Windows Server portfolio into a single server which was very easy to manage. For the first time, small businesses were able to compete in the global marketplace alongside their enterprise rivals — realising the benefits of identical technologies, but without breaking the bank. Many companies sought a collaboration server like Exchange to manage all their communication better than they could achieve with conventional email systems. This was undoubtedly one of the most popular products to be bunded with SBS, and one which enabled many to thrive and flourish.

I owe a lot to SBS — in fact, without it, I would not be writing this article. Regular contributors at Experts Exchange may be aware that I began learning about networks and servers when I built my first server at the age of 11 to run the family computers. That server was running SBS 2003. Back then, my knowledge of networking was non-existent, but over time and with the supportive guidance from my peers at Experts Exchange, I was able to learn. I work now with a few organisations from 5 users up to several thousand, managing their infrastructure and developing solutions to help them integrate technology into their business model to position themselves and grow. For one such company, having an office staff and a snazzy computer system is unheard of in its industry, yet I have watched them develop from a small setup with a single laptop and a home office to a very successful company in their own right — and they give credit to their SBS server for helping make that happen.

So what’s the alternative?

Well, it’s not all bad news, and no, that’s not because I’m advocating we make what we already have the de facto standard for the next umpteen years and stop innovating. The replacement product comes from the Windows Server 2012 range, which has been massively revamped and simplified. It’s called Windows Server Essentials. This supports a maximum of 25 users on a single physical server and provides many of the services expected of a local server. Unfortunately, there’s a drawback. No Exchange Server. Companies are encouraged to push email hosting away from the local premises to Office 365 in Microsoft’s public cloud. The Essentials server provides integration with the Office 365 cloud to manage and control the service. It does still provide support for an on-premises Exchange Server and there is the option to use Windows Server 2012 Standard, which now allows a physical host and 2 virtual servers under a single license. However, the licensing for that must be acquired separately. Quite understandably, this strategic change in the rules of engagement has caused much controversy.

I understand and fully appreciate the intention of cloud-based computing – moving the infrastructure away from individual companies to service providers and large datacentres, increasing reliability and managing cost for the end-user. The model makes sense on the surface and has been enjoyed by many for years – consider Hotmail, one of the first cloud-based email services, joined rapidly by Yahoo! and Gmail in the late 20th and early 21st centuries. The technology is not new. Indeed, Google, Microsoft, Apple et al. have been successfully pushing it for years. What is new and scary is the paradigm shift which is trying to immerse the business sector kicking and screaming into the cloud before the technology is proven. There are many issues blocking adoption of the cloud: compliance, conflicting privacy laws between countries (where the service provider is in one and the user in another) and the lack of affordable, high-speed Internet connections in all corners of the globe. For these reasons, I am not convinced that cloud is the way forward for business (and apparently, neither is Steve Wozniak). I want to know exactly where my data is and have complete control over who is permitted to access it. I cannot afford to entrust such data to another individual. If everything is in my hands, it’s my fault and my fault alone if something goes wrong. On the contrary, in the cloud, it’s impossible to know exactly what is happening to your data, nor is there any guarantee today’s data will still be there tomorrow.

There is always difficulty effecting change in just about any situation, but this becomes very prominent when the impact is global. At first, I was saddened by the loss of SBS, but at least I know there are valid options for the future. I am concerned over the direction of the IT industry and the forced shift of companies to the cloud. It is a very big worry, and many IT professionals feel their entire livelihoods have been torn from beneath their feet. However, we cannot stand still. As Paul Cunningham of exchangeserverpro.com says in his news article on this story, This is IT. Things change. You either change with them, or you die too. We do, however, need to be very careful how we play the hand we have been dealt, and moving leaps and bounds into the cloud is not a card I am about to play any time soon.





ADMX files, where to put them, and you – take 2

4 05 2012

A few years ago, I wrote a blog on the storage location of ADMX files. For Group Policy, these files are crucial, as they define the settings you see in the Group Policy Editor, and by extension, they describe the registry settings which need to be managed on each client workstation to which a policy is applied.

(Contrary to popular belief, the Group Policy Engine on a client does *not* need to refer to these files to actually apply Group Policy. The Group Policy Editor parses the file and stores the specific registry modifications in the appropriate location in the SYSVOL folder structure. The editor does, however, require access to all the proper ADMX files to allow an administrator to make policy changes)

The ADMX format was introduced in Windows Server 2008 and Windows Vista and is XML-based, unlike the previous ADM file syntax of Windows Server 2003, which was a custom syntax which proved challenging at times.

In my earlier post, I specified that the best location to store these files is %systemroot%\PolicyDefinitions on each of your DCs. This was in response to a specific problem I had at a customer with a new, single, standalone Domain Controller.

However, on much larger networks, this advice is not something I would endorse. By storing the policies in the PolicyDefinitions container on each DC, the ADMX files will only be available in the Group Policy Editor on that particular Domain Controller. If you want to use Group Policy Management Console from a workstation, another DC or a member server, then you are going to have many settings which have no policy definition, so you will be unable to manage them. With products like Server Core (a particular focus of Windows Server 8 Beta), managing Group Policy from the DC’s desktop is no longer a recommended or particular routine operation. Similarly, managing a DC directly from its desktop for such routine changes is not a best practice – delegating control over Group Policy and making the changes on a workstation would be a better choice. So, we need a better way of sharing the ADMX files across the entire LAN to ensure they roam to any machine where policy may be set.

Fortunately, Microsoft already have a solution. It’s known as the Central Store. Essentially, this is a PolicyDefinitions folder within the SYSVOL folder hierarchy which you already know about. By placing the ADMX files in this directory, they are replicated to every DC in the domain; by extension, the ADMX-aware Group Policy Management Console in Windows Vista, Windows 7, Windows Server 2008 and R2 can check this folder as an additional source of ADMX files, and will report them accordingly when setting your policies.

By default, the folder is not created. Whether you are a single DC or several thousand, I would strongly recommend you create a Central Store and start using it for all your ADMX file storage. It really does work well.

More information and detailed procedures are available from Microsoft Support.





iPhone 4S, Exchange ActiveSync and internal wifi

30 04 2012

It has been known for a while that iPhones and other iDevices do not play well with Exchange ActiveSync when roaming between a public network (such as 3G) and a private internal network to which the Exchange Server is connected. In particular, push email often does not work, which seems to be a bug in the iOS software. It’s a known issue, according to Apple. However, it caught me out recently, because the problem seemed to go away for a long time with the release of the iPhone 4.

At work, we have a set-up which is quite common for organisations of our size. We have two distinct networks: the internal network, which is reserved only for trusted devices owned and managed by us (the PCs, laptops, printers, switching gear, servers and now, thin clients). With 1000s of devices on this network, it is VLANed quite heavily to increase manageability, although I will admit this project was something I only completed fairly recently. Before last year, it was a single broadcast domain… but that is another story.

However, we also have a guest network. The guest network is isolated into its own VLAN, and is for wired clients which cannot authenticate as domain members (via 802.1x authentication) or for wireless clients connecting via a “Guest” SSID issued by our wireless controller. The guest network is still restricted to internal use – users authenticate to our RADIUS servers from their phones or laptops. Provided they provide valid credentials, they are provided with restricted access to the Internet.

All of the networks are linked together by our Forefront TMG deployment. This is driven by our inbound ISP connection and exposes several interfaces to the network – the internal network has two, teamed interfaces (for redundancy and throughput for data from cache) and the guest network has a further interface. The TMG deployment is the gateway for the guest network, and the internal network has a 0.0.0.0 default route for unresolved traffic crossing the VLANs.

When the Forefront TMG was provisioned last year, I initially configured the guest network both for internet access, but also with an internal set of “relay” rules, if you like, for access to certain resources on the internal network – OWA, RD Web Access, our management system, internal websites and, crucially, DNS lookups via our internal name servers. In effect, guest traffic was not NATed onto its own public IP. When it matched a firewall rule for one of our internal services, it was simply routed into the internal network. This made the deployment much simpler, and meant the internal IP addresses returned by internal DNS nameservers would still work for guest clients. Upshot: I don’t need more nameservers!

At the time, this did not pose a problem, even with the iPhone and iPad devices used by our staff. These phones could have been on 3G and wifi simultaneously, and we never had an issue with the mismatched IP addresses on the two networks stopping ActiveSync working.

That is, however, until someone upgraded to the iPhone 4S.

As noted in the blog post linked above:

“push” may stop working if your company’s Exchange ActiveSync server has a different IP address for intranet and Internet clients. Make sure the DNS for your network returns a single, externally-routable address to the Exchange ActiveSync server for both intranet and Internet clients

The problem experienced with this one iPhone 4S user went beyond push email. The user’s phone worked perfectly when away from the network. However, the moment it roaming onto our wifi, it seemed to have an adverse effect on the Exchange account configuration. Almost immediately, the phone would report a password error on a manual email check. The Exchange account would then refuse to work at all – on any network – until the user deleted the device from the Exchange Control Panel (ECP), switched back to 3G and re-created his connection.

I was not convinced the issue was with Exchange – all manner of other devices, even the iPhone 4, were still working. Nothing tested incorrectly. The problem was not a user issue, as I had him configure a test user account for a few days. Same problem.

Eventually, after a lot of painstaking troubleshooting (and waiting for feedback), it started to become very clear the issue was present only on the iPhone 4S and only in certain circumstances. However, it was much more serious than before – when the issue occurred, it did not just stop the iPhone from working until it roamed off-site again. It essentially wrote the email capability on the device off.

The resolution was a simple one, and one I should probably have implemented in the first place. The Forefront TMG deployment was re-configured. No routing was permitted between the internal network and the guest network. Instead, I added a network rule for guest network traffic to be NATed to its own public IP. I built a new cluster of standalone DNS servers, which serve two purposes – recursive lookups from the internal network (they are, effectively, caching servers) and hosting of the public DNS zones which return public IP addresses for all our network services.

When the guest network was given access to these nameservers, the iPhone 4S problem immediately went away. As detailed by Apple, it seems their devices are once again having issues with multiple IP addresses being issued by DNS for the same service. I thought this inconvenience had been resolved, but it would appear this design strategy will be going back into my network design methodology in the future. In any event, it did allow me to streamline and simplify our guest network configuration, which is always a good thing!

Watch out for Apple devices and the problem with issuing different internal and external IPs if they are used on your internal wifi. Either make the public IP routable internally and use that for internal access, or – a very common solution – don’t use them on wifi at all.





Exchange Server password expiry handling on iPad/iOS 5

31 12 2011

Overnight, the password for my Exchange account expired, as would be expected in line with my security policy.

Unfortunately, it would appear there is a bug in iOS 5’s handling of this situation. My iPad (running iOS 5.0.1) had many, many “incorrect password” prompts when I picked it up to use it this morning. There were so many that I was about to concede that the iPad as unusable until I found a computer to change my password on, as the password was yet to be set to a new value.

I would usually change my password directly from the iPad, by logging in to OWA, where I have enabled the ability to change a password when it has expired.

After some time of pressing “Cancel”, I was finally relinquished from the grasp of this prompt and was able to proceed to use the iPad normally.

It would appear to me that the number of prompts would be equal to either the number of Fetch attempts since the password expired and/or the number of occasions the iPad has tried to open a session for push delivery from the server. Of course, the iPad would have failed on every occasion, and it would appear it is being extremely verbose by displaying each and every failure.

Either way, the code should detect an incorrect password and show the “Incorrect Password” pop-up once only, as was the behaviour I experienced on iOS 4. If I choose to dismiss that message, I should not be repeatedly prompted with the same alert. As a tech savvy user, I repeatedly hit “Cancel”, but many of the users I deals with on a daily basis would try this a couple of times and then assume their iPad was unusable and not continue for fear of “breaking” something.

It seems I am not the first to come across this issue, but I will add my voice to those who hope this issue is resolved in a future iOS release.

For Exchange and AD admins, be aware this issue could potentially lead to lockout situations, dependent on your security policies.





Missing some cmdlets at Exchange Management Shell? Me too!

11 11 2010

On one of our many Exchange Servers at work, I recently discovered the Exchange cmdlets in the Management Shell which I rely on for my daily Exchange management had disappeared. get-excommand reported just one Exchange cmdlet was loaded: Get-ExchangeDiagnosticInfo. Strange. They were there one day, gone the next. No, it wasn’t caused by an update to the best of my knowledge; it didn’t happen over our patching window.

The case of missing cmdlets was traced back to an issue with my user profile on this server. A test with another user account yielded no issues at the Management Shell.

A quick fix to this might be to obliterate the user profile using the System applet Control Panel, then log back in and have Windows generate a new profile. However, this is totally unnecessary and you’ll lose any special configuration, given how simple the actual solution is.

Exchange Management Shell uses a directory in the user’s roaming Application Data to store the Powershell module configuration settings. My module data had some… modifications. I don’t know the source of these changes, but it rendered the cmdlets missing. I suspected this was the case because shell loaded much more quickly than normal when it was broken – rather than show the status of the pending implicit remoting session, which I am used to seeing, it loaded and connected almost instantaneously.

The solution is to remove the C:\Users\username\AppData\Roaming\Microsoft\Exchange\RemotePowershell\your.domain.com directory.

After deleting this directory, restart the Shell. The startup process will create the directory and re-generate the module files, fixing your issue and allowing you to get on with whatever you needed to do!

Matt

P.s. I know I’ve been quiet lately, and for that, I apologise. For the past couple of months I’ve been involved in an almighty migration job, away from an awful managed service network (tip: NEVER opt for an outside company to supply your network. It falls apart!) to a vanilla Windows Server system. This came not a moment too soon but completing a migration of this magnitude for 2500 seats in the 6 week maintenance window is no easy feat!

I do have some articles on the backburner, and hope to get some out to you ASAP. Thanks for your patience, and thanks for reading!





Windows XP Favourites Redirection – ADMX files

3 08 2010

One of the major disadvantages of still running XP in production is its lack of Internet Explorer Favourites directory redirection. If your users frequently roam between computers, the usual workaround is to enable Roaming Profiles to have the favourites roam with them. This usually works, until Windows Vista or 7 is introduced into the environment.

The newer Microsoft operating systems from Vista onwards do not support the old, legacy format of the XP profile. Instead, users logging on to a modern OS for the first time will be given a new roaming profile with “.V2” appended to their username in the roaming profile share. This is the version 2 profile, used by Vista up and totally isolated from the XP profile, including total isolation of the data it contains. In a phased roll-out of the newer Microsoft operating systems, you must follow best practices by using folder redirection to redirect user data on all systems to a common network location. This removes the data from the profiles, maintains consistency and ensures the user experience is the same on all network stations, without concerns over which OS is installed and therefore which profile and data the user will have access to. Plus, roaming profiles are just too slow for storing lots of user data anyway.

Unfortunately, Windows XP does not support redirection of the Favourites directory; this support was added in Windows Vista. One workaround I have seen is the built-in Vista redirection configured to redirect user favourites folders on newer systems to the legacy XP roaming profile share. This works, but it’s not particularly clean; redirecting data to a profile share rather than a user (home folder) share just isn’t right. It also causes data loss issues if a user’s profile must be reset; I work by the principle that only disposable data – stuff the users could live without – should be put into a user’s profile for precisely this reason.

Implementing Favourites redirection in Windows XP is a logical alternative; it isn’t particularly difficult either. I developed the following ADMX files to supplement the older ADM solutions which are available through a search on a popular web search engine. With 2008 or 2008 R2 Domain Controllers, the ADMX format is available for your use and I would highly suggest you make use of it. ADMX is XML-based and much, much easier to use than the legacy ADM language.

XPFavouritesRedirect.admx

<policyDefinitions revision="1.0" schemaVersion="1.0">
  <policyNamespaces>
    <target prefix="customFavorites" namespace="Microsoft.Policies.Favorites" />
    <using prefix="inetres" namespace="Microsoft.Policies.InternetExplorer" />
  </policyNamespaces>
  <resources minRequiredRevision="1.0" />
  <supportedOn>
    <definitions>
      <definition name="SUPPORTED_IE5" displayName="$(string.SUPPORTED_IE5)" />
    </definitions>
  </supportedOn>
  <policies>
    <policy name="IE_Favorites" class="User" displayName="$(string.IE_Favorites)" explainText="$(string.IE_Favorites_Location_Explain)" presentation="$(presentation.IE_Favorites)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders">
      <parentCategory ref="inetres:InternetExplorer" />
      <supportedOn ref="SUPPORTED_IE5" />
      <elements>
        <text id="IE_Favorites_Location" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" valueName="Favorites" required="true" expandable="true" />
      </elements>
    </policy>
  </policies>
</policyDefinitions>

XPFavouritesRedirect.adml (name this the same as the ADMX file and dump it in the language folder in your PolicyDefinitions directory)

<policyDefinitionResources revision="1.0" schemaVersion="1.0">
  <displayName>
  </displayName>
  <description>
  </description>
  <resources>
    <stringTable>
      <string id="IE_Favorites">Location of Internet Explorer Favorites</string>
      <string id="IE_Favorites_Location">The path to the favorites folder</string>
      <string id="IE_Favorites_Location_Explain">Specify the path to the location of your Favorites folder. This is stored in an expandable registry string value, so you can use environment variables, such as %HomeDrive%%HomePath%.</string>
      <string id="IE_Favorites_Location_Tip1">Specify the UNC path to the favorites location</string>
      <string id="InternetExplorer">Internet Explorer</string>
      <string id="SUPPORTED_IE5">at least Internet Explorer v5.01</string>
    </stringTable>
    <presentationTable>
      <presentation id="IE_Favorites">
        <textBox refId="IE_Favorites_Location">
          <label>Path:</label>
          <defaultValue>
          </defaultValue>
        </textBox>
      </presentation>
    </presentationTable>
  </resources>
</policyDefinitionResources>

The above is standard ADMX/ADML format which can be dumped in the correct locations of your Central Store (if you don’t have one, why not? Set one up, otherwise you will need to store them in the local store on each DC). In the GP Editor, it will appear as a policy in the standard Internet Explorer area under the User Configuration / Windows Components node.

The Favourites registry value in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders is of type REG_EXPAND_SZ. The ADMX implements this with the expandable=”true” syntax, meaning from your perspective, you can specify environment variables in the GPO and these will be properly expanded by the system to their full paths. I personally use %HomeDrive%%HomePath%\Favourites to direct them to a subfolder of the user’s defined home folder location in their Active Directory user account properties.

This does not move any existing Favourites out of the profile and into the redirected location. However; this is fairly easy to script in a logon script or one-time operation. For new users, the Favourites directory will be created automatically, assuming the home drive exists, the user has permissions, quota is not fully used and so on.

It is a good idea to set the XP Favourites redirection policy in its own GPO object, then apply a WMI condition to filter the policy to XP/2003 and older systems only. Windows Vista and above support native redirection of Favourites, so you should use a separate, WMI filtered policy for Vista+ computers to redirect their Favourites to the same location as defined for XP clients.





APC Powerchute vs. Windows Power Management

1 08 2010

I was recently trialling APC Powerchute on a small SBS 2008 server, attempting to maintain some automated shutdown while also gleaning some stats on how frequently the UPS was intervening. I’ve used the software before, but this time it refused to play ball; I saw the stats, but it never shut the server down on power failure. Not good; I’d rather know the data was safe than be told how many times it wasn’t safe.

So, I reverted to the fallback option. An APC UPS (the USB connected ones, not sure about serial) can run under Windows’ power management, being configured and monitored in exactly the same way a battery in a laptop would. Thus, they truly are plug-and-play; some less reputable brands require their own monitoring software and aren’t nearly as effective in my experience.

Alas, uninstalling the software never restored Windows Power Management. I waited… rebooted… checked control panel… nothing. No mention of a battery in the power options and the power meter icon was disabled in the task tray. I’d lost all shutdown functionality from the UPS. Yet again, a routine job involving a computer turned in to a match of man vs. machine.

The fix was surprisingly simple, didn’t involve edits to the registry (which I fear when it comes to drivers and hardware and critical things like power) — but unintuitive:

  1. Open Device Manager, expand Batteries, locate the UPS and uninstall it. Be sure to uninstall the driver too when asked
  2. Wait a few minutes for that to complete, then on the Action menu, hit Scan for hardware changes
  3. Sure enough, the UPS was detected again, the drivers installed fresh and my power icon in the task tray immediately restored

It would appear APC Powerchute doesn’t fully tidy up after itself.