On several occasions I’ve noticed that Comcast seems to be blocking port 25 on their internet connections. This, of course, is an issue for SBS 2011 networks and outgoing SMTP email. For most cases I use a Smart Host for outbound email such as DynDNS. However, the built in wizard for configuring the Smart Host does not allow you to specify which port to use. Fortunately, with two simple powershell commands you can change this.
Open Exchange Management Shell (EMS) as an administrator.
Type the following cmdlet to list all the current Send Connectors.
Using the SMTP Send Connector name extracted from the above cmdlet type the following cmdlet to change to the desired port. (2525 in this case)
[note]Set-SendConnector “SMTP Send Connector Name goes here” -Port 2525[/note]
Whoa. Wait. Did I just say Windows Azure Linux VM? Yes. I sure did. Microsoft recently announced the General Availability of the Windows Azure Linux Virtual Machines. We’ve been looking for a good hosting solution, so I thought this would be a good time to do some experimentation on the Microsoft Azure Cloud.
I fired up a OpenLogic Centos 6.3 Virtual Machine. The process to get the machine running was amazingly quick and in just a couple minutes I was logged in via SSH. My next step was to install cPanel & WHM. The install script would start, run for a couple minutes, and then give a few “No package kernel-headers available.” Finally it would abort with the following fatal error.
[highlight](FATAL): yum failed 6 times. Cannot continue! Removing /root/installer.lock[/highlight]
Fortunately there is a simple fix. Simply install the kernel-headers by running the following command.
[highlight]sudo yum –disableexcludes=main install kernel-headers-2.6.32-279.14.1.el6.openlogic.x86_64[/highlight]
Restart the cPanel installation script and it should install successfully now.
A Windows SBS 2011 server at one of our customers locations installed several updates last evening, and when they came into work this morning they discovered they were not receiving any email. Neither was the remote web workplace or OWA working. After some digging around I noticed the following error in the event log.
[highlight]The Module DLL C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\exppw.dll failed to load.[/highlight]
I tried a number of solutions that I found online, but none of them worked. Somewhere though I saw a tip that mentioned downloading Exchange 2010 SP3 and doing a reinstall of the Service Pack. Sure enough, I noticed that one of the updates that was installed last night was Exchange 2010 Service Pack 3. I downloaded the SP from Microsoft’s servers and reinstalled it. This fixed the above problems immediately.
[note]Note: I never set Windows Servers to install updates automatically. I still don’t understand how the updates got installed and the customer is pretty sure they didn’t tell the server to install them.[/note]
One of the biggest complains we get from customers that are using Microsoft Office 365 is the mandatory password expiration. Microsoft has a KnowledgeBase article that explains with a few simple powershell commands how to disable this and set the passwords to never expire.
Connect to the Windows Azure Active Directory Module for Windows PowerShell by using your company administrator credentials. For more help on this step, see this article on Technet. Note: This also used to be called Microsoft Online Services Module for Windows Powershell.
Connect to your Office 365 service using the following cmdlet. Enter the Administrator username and password for the Office 365 service.
Run the following cmdlet to change all the user accounts passwords to never expire.
[highlight]Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $true[/highlight]
This has worked very well for us and makes the customers very happy as the password expiration can be a hassle especially for small businesses.
One of the issues you will run into when migrating from an on premises Exchange 2010 server on SBS 2011 is that Outlook will not autodiscover the correct Office 365 server settings. Fortunately this can be easily solved with a few simple PowerShell commands.
Open an Exchange Management Shell as an administrator. (Elevated PowerShell)
Use the following command to discover the Identity name of your Autodiscover Virtual Directory. Either note or copy the values in the Identity field.
[highlight]Get-AutodiscoverVirtualDirectory | fl Name, Server, InternalUrl, Identity[/highlight]
Use the following command to remove the AutoDiscover Virtual Directory. Be sure to replace the text inside the quotes with the value in the Identity field above.
[highlight]Remove-AutodiscoverVirtualDirectory –Identity “Insert identity value here”[/highlight]
You will have to confirm the removal by hitting Y for yes when prompted. You can double check to see if this worked properly by rerunning the command in step 2. You should get a blank result if successful.
That should be it. Your Outlook clients should connect successfully to the Office 365 service.
I was troubleshooting a Windows 8 laptop that wouldn’t connect to a customer’s wireless network recently. The wireless network was configured using the WEP – Shared Key Authentication method which is horribly insecure and should never be used. After doing some diagnosing and researching I discovered that Windows 8 has dropped support for WEP – Shared Key Authentication. My solution to the problem was to inform the client that he needs to switch to a newer and more secure method of encryption.
[note]WEP – Shared Key Authentication has been deprecated and is no longer supported in Windows 8.[/note]