
A preview version of the next iteration of the Small Business Server product, SBS7 or "Aurora", has been made available by Microsoft to download and install for trial and evaluation purposes - https://connect.microsoft.com/SBS
Comprising a Server 2008 R2 Domain Controller, File & Print Server and Terminal Services Server, the product also includes Exchange Server 2010 SP1 as well as Sharepoint 2010 Foundation Server.
As many companies tend to skip a version of Microsoft products before upgrading, SBS7 will be attractive to existing users of the Small Business Server 2003 product, and to new customers looking to deploy a one-box solution to handle all of their server needs for up to 75 users.
SBS7, perhaps in response to Google's increasing customer base of "cloud-based" workers, has placed the emphasis very much on remote working. The remote workplace portal site provides one-click access to Email (via Exchange Outlook Web Access), file shares, remote desktop access (via Terminal Services) as well as the company intranet and any Sharepoint web applications that have been deployed.
As SBS7 comes with Sharepoint 2010 Foundation Server, it is possible for companies to deploy the Microsoft Office Web apps product, which enables users to create, view and edit Office documents via their web browser with no need for Office to be installed on their local machine.
The Exchange 2010 installation also includes Exchange's Unified Messaging role, providing the ability for integration with your SIP-based IP phone system for features such as Outlook Voice Access.
Outlook Web Access, running on Exchange 2010, provides the full rich desktop experience on a wide range of web browsers including Firefox, Safari and Chrome besides just Microsoft's Internet Explorer as with previous versions of Exchange.
File shares are also accessible via the portal:

Sharepoint-based Document Spaces allow users to view and upload a wide range of documents:

as well as manage Office documents directly from their web browser with no local Office applications installed:

I have looked at the features available in Exchange 2010 as well as the enhancements included with Exchange 2010 Service Pack 1 in other posts previously. For businesses looking to upgrade their existing Exchange infrastructure, Exchange 2010 offers some compelling functionality:







The RemoteApp capabilities of the Server 2008 platform are included in SBS7 - the feature that allows you to publish an application installed on the server itself, or on a machine on the local network, for use remotely by clients that do not have the application installed: ideal for managing software licenses and restricting access to applications to only those who should have it, and also enabling users to work remotely on personal equipment.
Now named Remote Desktop Services, the feature is not installed by default on a clean installation of SBS7 but can be added via the Server Manager.
Once installed, applications can be published in the Server Manager:

and then published to the Remote Desktop web interface

which can then be accessed by users remotely (https://(sbs_server)/rdweb):

Enabling users to access and run the application remotely. NOTE client PCs will need to support the Remote Desktop Client 6.1 to use this feature (ie Windows XP SP3 or later, not Mac or Linux platforms)



Sharepoint is Microsoft's collaborative working and web portal product, bundled with SBS7. At a simple level it can be used to quickly and easily deploy a company intranet containing a document repository, address book, announcements and links to other pages.
If used to the full, it can provide an effectively project management tool, with workspaces assigned to specific teams, accessible based on AD security groups, with shared calendars, blogs and wikis. Sharepoint isn't my area of expertise I'll be honest so visit the Microsoft web site for more detailed information.
You can read more information about Microsoft Small Business Server on the SBS web site here - http://www.microsoft.com/sbs/en/us/default.aspx
This is slightly off-topic, but I wanted to install OCS 2007 Server, not having done it before, in order to be able to then test connectivity from other devices including BlackBerry, and Android if/when a client is made available. Normally I wouldn't blog about the installation of a relatively common Microsoft server product, but I ran into a number of errors so thought I'd detail how they were resolved in case anyone else runs into the same problems.
The procedure I ran through was as follows:
Raise the Domain Functional level from Mixed Mode to Server 2003 Native Mode
On the domain controller, open the Active Directory Domains and Trusts MMC snap in. Right click on the Domain and select the option to Raise Domain Functional Level. If the domain is set to Mixed Mode, it will need to be raised to Server 2003 Native Mode.

Click OK and then run a gpupdate /force command to force the change to replicate through the domain.
Create required service accounts
Create a new domain User Group called 'RTCSetupDelegate'.
Create two new domain user accounts: 'RTCService' and 'RTCComponentService' and add them both to the RTCSetupDelegate group created earlier.
Launch the OCS Installer
Log into the OCS server with a domain user account with both local admin rights on the OCS server and SchemaAdmin rights on the domain.
Launch the OCS installer application, if prompted to install the Visual C++ redistributable, select Yes.
Run the Forest Prep wizard followed by the Domain Prep wizards and ensure they complete successfully. Once completed, run another gpupdate /force command on the domain controller to force a replication throughout the domain.
Delegate setup tasks to required service accounts
Delegate the setup and administration tasks to the two RTCService user accounts created earlier. Launch the Command Prompt and navigate to the directory containing the OCS installer files. Browse to the \setup\i386 directory.
Run the following commands:
(Read the following Microsoft Technical article for full information - http://technet.microsoft.com/en-us/library/bb905930.aspx)
To delegate Setup:
LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:SetupAdmin
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com
To delegate Server Admin:
LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:ServerAdmin
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com
To delegate User Admin:
LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:UserAdmin
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com
/UserOU:CN=Users,DC=domain,DC=com /UserType:User
To delegate Read Only Server Admin:
LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:ReadOnlyAdmin
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com
To delegate Read Only User Admin:
LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:ReadOnlyAdmin
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com
/UserOU:CN=Users,DC=domain,DC=com /UserType:User
Run the Deploy Server wizard to install the required program files to the server. At the end of the installation, the wizard will then attempt to activate the OCS server. If the wizard fails with an error along the lines of 'the server clock may not be set correctly', again verify that hotfix 974571 is NOT installed on the server. If it is, uninstall the hotfix, then attempt to activate the server manually at the command line with the following command:
LCSCmd.exe /Server:ocs.domain.com /Role:SE /Action:Activate /Password:PaSSword1
(where PaSSword1 is the password of the user account used to install the OCS software - the account currently logged in, not the RTCService account)
Return to the OCS installer wizard and resume where you left off.
Issue a certificate request to the online CA and assign it to the OCS server. Start all OCS services.
Under the "Deploy Other Roles" section, select the option to deploy the Communicator Web Access server role, assigning the certificate generated earlier when prompted.
If all has gone well, you should see the server roles listed within the Office Communicator Server MMC snap-in within Administrative tools, and several new context menu items within Active Directory:


The Communicator Web Access (CWA) web site should be listed in the CWA MMC snap in:

And browsing to https://(server)/cwa should display the Communicator Web Access login screen:

In my next post I shall detail how to set up the BlackBerry Enterprise Server solution to enable access to OCS from BlackBerry handheld devices.
I have blogged about the terminal services capabilities of Microsoft Server 2008 on previous, now defunct, blog sites and as it came up in a support call today I thought it was worth resurrecting my old article.
Terminal Services is a component of Microsoft Windows and Windows Server. If you have used Remote Desktop to remote control another Windows-based computer, then you have used terminal services already. It is so-called after the days when computing power used to be consigned to a central mainframe, and remote thin-client “terminals” would be used to access the processing power and applications held on that mainframe.
Simply put, Terminal Services allows users to access centrally-located application resources: suppose a user needs to edit a document written using Word 2007, but doesn’t have Word 2007 on his or her PC, and can’t justify the expense of a license for Office 2007 as they may only need to edit an Office 2007 document once in a blue moon – they can access a legitimately-licensed copy of Office 2007 installed on a terminal services server for the length of time they need to do their work, and then when they have finished, this application is then free for someone else to use, without having to install and then uninstall the software from their PC to maintain licensing adherence: the application has been “virtualised”.
At this point I should mention that this is probably not a good example: there are converters available for Word 2007 which can be used with previous versions of Office. Quark, perhaps, would have been a better example, but I’d already taken lots of screenshots of running Word 2007 in a remote terminal session before I started writing this post!
Windows Server 2008 has extended upon the terminal services capabilities of previous versions of the operating system.
Server 2008 Terminal Services Remote Application requires that the client machine be running Remote Desktop version 6.1 – in real terms this means Windows XP Service Pack 3, or Windows Vista Service Pack 1. This can be installed via Windows Update if not already installed.
The principal difference between this release and previous implementations, is that with Server 2003 and prior, applications were run in a remote desktop session, whereas with Server 2008 applications are still running “remotely”, but appear to run on the local machine desktop as if they were installed locally: the same remote desktop protocol is used, but the single application loads and is displayed in single application window, alongside other running applications, rather than the entire desktop of the remote machine. The remote application has its own entry in the taskbar along with local applications, and the window can be maximised and minimised as well as resized, as with local applications. The remote application can also use the “notification area” on the local PC (the system tray). Local drives and printers can also be directed to the remote application.
As far as the user is concerned, they have no means of knowing, necessarily, that the application isn’t running on the local machine, virtualisation technology hiding the physical characteristics of the application from the end user.
Applications can be accessed in two ways:
RemoteApp programs can be launched in a number of ways: an RDP file can be launched from the client PC, which contains details of the program’s location, as well as security parameters concerning what the application can access on the local machine, or alternatively the remote application can be installed on the PC from an MSI file, which adds the program to the Start Menu and associates the correct file extensions for use with the application.
Terminal Services Web Access enables users to launch applications by selecting them from a web site.
Benefits
Besides the benefit of ease of license administration, there are other clear benefits: client devices can be used simply as thin-clients: no data need be stored on the local machine, meaning that should a laptop be lost or stolen there is no sensitive information held on it.
There is no need to keep multiple copies of the same application installed on multiple workstations, kept up to date and patched: only a single copy of the application needs to be maintained.
Because the application is running on central hardware that is more than capable of running that application, the client hardware does not necessarily need to be able to run the application natively. Therefore PCs that could never hope to run Office 2007 locally can access it – provided that they support the Remote Desktop Protocol (RDP).
As opposed to Remote Desktop, which transmits the entire desktop to the remote user, and can quickly generate a large amount of data to be transferred; application virtualisation only requires that key-presses and mouse movements be transmitted over the network (and the remote session can be encrypted using TLS encryption is desired). This means that relatively “complicated” applications can still be accessed even over low-bandwidth connections. Also, because the data that is sent between client and server can be encrypted, applications can be accessed remotely even when out of the office, without the need for a separate VPN infrastructure.
This remote access technology can also be combined with Server 2008 Network Access Protection (NAP) technology to ensure that remote clients can only access the application server if they have current anti-virus definitions and meet 'baseline' security requirements defined by the administrator.
Configuring the server
The Terminal Services role is added to the server via the Server Manager application. If you wish to use the Web Access component, then the Web Server (IIS) role should be added also. Once installed, the TS RemoteApp Manager will be listed within the Server Manager:

Applications installed on the server can be “enabled” for RemoteApp use selecting the Action to Add RemoteApp Programs. The Add RemoteApp Program wizard will be displayed:

Click Next. A list of available applications will be displayed:

Select the application(s) you wish to enable and click Next

Click Finish. The wizard is now complete and the applications are enabled. Available applications are listed in the RemoteApp Programs window pane:

Right clicking on a program allows the administrator to create an RDP or MSI configuration file for the application which can be deployed to the client machines. Applications can also be hidden or added to the Web Access view from here:

Selecting the option to create an RDP file will launch the RemoteApp Wizard:

Click Next. Specify the location where you wish the RDP file to be saved, and also configure certificate and Terminal Server Gateway settings:

A Terminal Server Gateway can be deployed in a DMZ environment which accepts RemoteApp from client machines and relays them through a corporate firewall to the Terminal Server on the local network. Click Next:

The wizard is now complete, click Finish.
Selecting the option to create a Windows Installer Package will launch the same wizard:

Click Next. Specify where you want the resulting MSI file to be saved and configure certificate and TS Gateway settings:

Click Next. Specify where on the client machine you want the resulting shortcut to be installed:

Click Next and then Finish.
Configuring the client
Once the RDP or MSI file has been created on the server, it will need to be copied to the client machine.
Running the MSI file will create a shortcut on the client machine in the location specified when the MSI file was created:

RDP files can be double clicked to initiate them. When launched, a connection to the Terminal Server will be established and the user will be prompted to enter a username and password to access the program:

Once authenticated, the user can then specify what resources on the local machine they wish the remote application to have access to:

The application will then load:

(the above screenshot shows that Office is not installed locally on the machine).
Web Access
By default, web access to the Terminal Server is located at http://(servername)/ts (https would be required if certificate-based access had been configured). The web interface will display a list of programs that have been enabled for web access:

Clicking an icon will launch the connection to the RemoteApp. The user will be prompted to specify what local resources the remote application should have access to:

The user will then be prompted to enter a username and password to authenticate the connection:

The application will then launch. The fact that the application is remote will be indicated by the presence of “(Remote”) in the name of the application window.

From an administrative point of view, web access is the simplest means of deploying applications: the client does not need an RDP or MSI file to be sent to it, the user simply needs the address of the web site.
Unlike previous versions of Outlook, Outlook 2007 uses (and therefore requires that it be installed), the Windows Desktop Search software.
In order for this to be able to search public folder content, these folders must be stored locally in Cached mode. Public folder caching is not enabled by default, and must be enabled in the Advanced properties of the Exchange Account:

Rather than sync the entire public folder directory, only “Favourite” folders are synced, therefore target public folders must be added to the Favourites before they will be cached and then indexed. To add a favourite, right click on the folder entry and select “Add to Favourites”:

Search results will now include the public folder favourites.

A while ago I set up a Google Apps Premier Edition account to see what was involved, and detailed the process in this article - http://blog.brightpointuk.co.uk/so-i-decided-set-google-premier-edition-...
Now that Microsoft have launched their own hosted Exchange, Lync and Office Web Apps service, I decided to see how easy it was set up my own fictional company on the platform.

Registering for a free, 30-day trial is simplicity itself: simply request a trial and enter details of your desired company name, which necessarily needs to be "xxxx.onmicrosoft.com"
Within moments you will have a fully functional Exchange 2010-based 10-user mail and calendaring platform.
Your new domain can be accessed by browsing to https://portal.microsoftonline.com and logging in with the credentials your specified when you registered for the service:

All administration of your domain via a web-based interface:

In order to start using your own domain for email, rather than the "xxxx.onmicrosoft.com" domain provided, you need to run through a short wizard to demonstrate that you have control over the selected domain. You will be prompted to create a spurious MX record for the target, which Microsoft will then query to prove that you have created the record, thereby indicating that you have control over DNS for that domain:

Once your domain has been verified, you have two choices: Microsoft can provide a hosted DNS service for you automatically with the correct MX records created already, all you need to do is to configure the domain to use Microsoft's DNS servers: "ns1.bdm.microsoftonline.com" and "ns2.bdm.microsoftonline.com":

You can then manage your DNS records, including adding new entries, directly within your Office365 web administration interface:

Or, should you prefer to use an alternative DNS provider, here you will see the MX record to use.
You should also create a CNAME alias record for "autodiscover.domain.com" pointing to "autodiscover.outlook.com" - this entry is used by the auto-configuration services of Microsoft Outlook and Exchange ActiveSync clients when they are trying to determine the email settings for your domain automatically.
You can now add email addresses to your user mailboxes as required. If you have not yet added user accounts, bulk import from CSV file is also supported:

and distribution groups:

Groups can be set to only receive email from within the organisation or from any source:

Although we have added new incoming email addresses for our domain, when sending emails, the provided "xxxx.onmicrosoft.com" domain will still be used.
In order to edit the primary SMTP address for users, this needs to be done via a PowerShell session as it does not seem to be possible to do it via the web administration interface (at the time of writing at any rate).
Launch a Windows PowerShell command prompt (available as standard on Windows 7 / Windows Server 2008, available for download for Windows XP / Server 2003).
Connect to your hosted domain by issuing command:
$LiveCred = Get-Credential
You will be prompted to enter your Office365 administrator username and password, the same details you specified when you registered for the trial.
In order to be able to run scripts, issue the following command:
Set-ExecutionPolicy -ExecutionPolicy unrestricted
Now connect to the Microsoft Exchange container:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
and connect the session to the local machine:
Import-PSSession $Session
Now connect to the target user mailbox you wish to configure:
$Mailbox = Get-Mailbox -Identity James
$Mailbox.EmailAddresses
Now define the email addresses assigned to the mailbox, with the primary email address being defined by entering "SMTP" in capitals:
Set-Mailbox James -EmailAddresses SMTP:james@joojanta.co.uk,smtp:james@joojanta.onmicrosoft.com
Repeat for other mailboxes you wish to configure.
When complete, disconnect the session:
Remove-PSSession $Session
Mails sent by your users will now appear as coming from your private domain.
You can now optionally change your user's default username to keep things consistent:


Running on Exchange 2010, your hosted Office 365 platform provides the same Exchange ActiveSync functionality that a locally hosted deployment would offer: access control rules can be defined to quarantine, block or allow devices requesting connectivity to Exchange; devices can have password usage policies enforced on them; and depending on which elements of the Exchange ActiveSync protocol the client devices supports, various hardware and software functionality can be enabled or disabled as defined by the administrator.


When configuring devices for Exchange email, if the device supports autodiscovery, by entering your Office365 email address and password, the device should be able to determine the remaining settings to use automatically. If prompted for a server address, use m.outlook.com
Authentication is done by username (email address) and password, there is no need to enter a domain if entering settings manually.
If your desktop email client also supports autodiscovery, then setting up the email account is a simple matter of simply entering your email address and password:


You can find out more information about Office 365 on the Microsoft web site - http://www.microsoft.com/en-gb/office365/online-software.aspx