Sam has been working in the IT industry for nearly 20 years now, and is currently working for VMware as a Senior Technical Marketing Manger in the Cloud Management Business Unit (CMBU) focussed on Automation. Previously, he has worked as consultant for VMware PSO, specializing in cloud automation and network virtualization. His technical experience includes design, development and implementation of cloud solutions, network function virtualisation and the software defined datacentre. Sam specialises in automation of network virtualisation for cloud infrastructure, enabling public cloud solutions for service providers and private or hybrid cloud solutions for the enterprise.
Sam holds multiple high level industry certifications, including the VMware Certified Design Expert (VCDX) for Cloud Management and Automation. He is also a proud member of the vExpert community, holding the vExpert accolade from 2013-present, as well as being selected for the vExpert NSX, vExpert VSAN and vExpert Cloud sub-programs.
Configuring WSS or SharePoint Services for a small client is a pretty effective way of getting a document management solution for a reasonable cost point. One of the limitations that caused headaches was that it used to have a maximum storage of 4GB, which was the database limit. If you wanted to go larger, you would need either a) multiple SPS installations, b) a full version of SQL server, or c) the full version of MOSS.
SSTP or SSL VPN connections are great for people working on client sites or behind very restrictive firewalls – they only require HTTPS (port 443) to be open to be able to connect. Unfortunately, you need to be running Windows 7 or Server 2008 (or newer) in order to make use of them. Threat Management Gateway 2010 is one option for an SSL VPN endpoint.
SSTP VPN Requirements Clients must be Windows 7/Server 2008 or newer Certificate – either commercial or an internal Certificate Authority Published CRL – SSTP clients check for the Certificate Revocation List of the CA If you already have an SSL listener (e.
Having recently managed several Exchange 2010 migration projects, one of the best new features which really sells it to systems administrators is the Online Archive. “No more managing PST files? When can we have it installed by?”
The problem is, once they’ve purchased licensing for Exchange 2010 and installed and configured the server, migrated the users’ mailboxes and decommissioned the old Exchange 2003 server, the Online Archive feature is not available.
While using the New-TestCasConnectivityUser.ps1 script to create a test user for Exchange 2010’s connectivity testing, I ran into an issue:
CreateTestUser : Mailbox could not be created. Verify that OU ( Users ) exists and that password meets complexity requirements. At C:\Program Files\Microsoft\Exchange Server\V14\Scripts\new-TestCasConnectivityUser.ps1:255 char:27 + $result = CreateTestUser <<<< $exchangeServer $mailboxServer $securePassword $OrganizationalUnit $UMDialPlan $UMExtension $Prompt + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,CreateTestUser Oddly enough, that OU does exist (as it will by default on any Windows Domain!
Disclaimer: this post is more for my own recollection than anything else! When it comes to Linux, I’m an amateur and everything I do from the simplest thing upwards is copy-and-paste from much more informed bloggers and websites!
My home server is running Ubuntu Linux 10.10 – access is via an SSH client only. I run an NFS file server for my home network, which stores my Music and Video for the network, and is running an iTunes server.
Recently I installed and configured a client’s new ESXi host, they’re a small company and only require a single host. The host in question was an IBM x3650 M3, an excellent workhorse for virtualisation and one of 5 or 6 of the same model that I’ve installed in the last year. In addition to the onboard Broadcom Dual Gigabit NIC, we always install at least a second Intel PCIx Dual Gigabit card for resilience/redundancy/performance.
If you’ve been here before, you may have noticed a couple of changes – the theme and name of this blog for example, and hopefully you’ve been redirected to a new URL! There are a couple of reasons for the changes, all of which are aimed at increasing the presence and visitor numbers on this site:
Branding. Whether I like it or not, “McGeown” is not easy to spell or remember so I wanted to move away from it as an identity.
Recently I needed to report on the ActiveSync devices that were attached to our Exchange 2010 organisation, and which users they were accessing, and then export them to a CSV file.
This is the script:
$ActiveSyncDevices = @() ForEach ($Mailbox in Get-Mailbox –Server MBX01) { Get-ActiveSyncDeviceStatistics -Mailbox $Mailbox.Identity –ErrorAction SilentlyContinue | Select DeviceFriendlyName, Devicetype, DeviceUserAgent | ForEach-Object { $_ | Add-Member –MemberType NoteProperty -Name "MailboxIdentity" -value $Mailbox $ActiveSyncDevices += $_ } } $ActiveSyncDevices | Export-csv c:\Path\To\File.
I can’t plead ignorance: I should know better! For years I have preached to users about the importance of strong passwords, regular password changes and non-proliferation of the same password, yet I’ve fallen foul of 2 of my own rules. My password is strong - 13 characters, random alpha-numeric, upper and lower case and including special characters - but has been re-used in a few places, and hasn’t been changed in a (long) while.
