[Today's post comes to us courtesy of Shawn Sullivan and Rituraj Choudhary]
Today’s post discusses the certificate distribution package on SBS 2008. The SBS 2008 self-signed SSL certificate that is installed in IIS 7 is a leaf certificate; meaning that the Issued to and Issued by names are not the same. Unlike SBS 2003, Certificate Services is installed as part of setup and a root Certificate Authority (CA) certificate is created to validate the server. If a client machine or mobile device trusts the SBS root CA certificate, it will trust any leaf certificate the CA issues. Therefore, if you change your external domain name and create a new self-signed SSL certificate through the Internet Address Management Wizard (IAMW), these clients and mobile devices will not have to install any new certificates into their stores. Here is an example of the SBS 2008 self-signed certificate:
Because we are now using a CA to assign our self-signed certificate, the distribution process has changed. Unlike the self-signed SSL certificate in SBS 2003, clients can no longer download and install the certificate when browsing RWW or OWA to trust it. To ease the process of certificate distribution to clients and mobile devices, a certificate installation package is created and shared on the server when you run the Internet Management Address Wizard (IAMW). Each time you run the IAMW, this certificate package is updated. It is accessible from the following paths:
The package contains both the root certificate and the InstallCertificate.exe application. Users can download either the compressed or uncompressed version of the package to a USB key, floppy, or CD ROM from the UNC path to install on their machines at home. The following is an example of a root certificate in this package:
Installing the Package
InstallCertificate.exe will install the certificate into the machine’s Trusted Root Certification Authority store when you select Install the certificate on my computer. You must be running Vista or XP SP2 or later.
If installing on a mobile device, it must be running Windows Mobile 6 or later. You must connect the device to a machine running either ActiveSync or Windows Mobile Device Center. The certificate will be copied to the device’s root drive and then installed natively by the Windows Mobile OS.
Domain joined clients do not need to install this package; they will already have this certificate in their trusted store.
The root CA certificate is valid for 5 years and the leaf certificates are valid for 2 years. Upon expiration, run the Fix My Network Wizard in the SBS Console to renew them.
**This package is not used if you have installed a 3rd party certificate from a trusted certificate authority using the Add a trusted certificate wizard**
[Today's post comes to us courtesy of Shawn Sullivan]
This post discusses an issue we have found with the FNCW and Exchange 2007. The symptom is that you receive the following error when running the Internet Address Management Wizard:
“The wizard cannot configure Exchange e-mail for your domain. To correct this problem, run the Fix my network task on the Connectivity subtab of the Network tab of the Windows SBS Console.”
However, when you run the FNCW to fix this issue, it fails and you receive the following error:
“The server cannot connect the SMTP connectors. Ensure that Exchange is running, and then try again.”
You will notice that none of the SMTP connectors in Exchange have been fixed as a result.
There are two possibilities that will cause this behavior:
NOTE: Replace ServerName with the hostname of your SBS 2008 server.
To resolve this issue, use the Exchange Management Console to either manually create the default receive connector or correct the authentication and permission group settings for the existing one. Afterwards, the FNCW will successfully fix your SMTP connectors.
To create a new connector:
When correcting the authentication and permission group settings for an existing connector, follow steps 7, 8, and 9.
[Today's post comes to us courtesy of Shawn Sullivan, Justin Crosby, and Edwin Joseph]
SBS 2008 is configured for Remote Desktop for Administration and TS Gateway during setup. However, it is not supported to install the Terminal Services role on the SBS server due to security, performance, and reliability purposes. Even though the installation of the Terminal Services role will not fail, you will receive the following error in Terminal Services Configuration when attempting to change the licensing mode from Remote Desktop for Administration to any other mode:
Unable to complete operation: 8007013D
In addition, the SBS Console will crash if you attempt to open any of the following links:
If you are experiencing any of these issues, you must remove the Terminal Server service from the SBS 2008 standard server (or Server #1 in SBS 2008 Premium) to regain proper functionality of the SBS console. You can do so by opening Server Manager, expanding Roles, and selecting the Terminal Services role. On the right hand side pane, select Remove Role Services and uncheck the Terminal Server role, click Next and Remove to complete the wizard. This is documented in the following KB article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;957712
If you wish to deploy the Terminal Services role in your SBS environment, we recommend purchasing SBS 2008 Premium, which comes with a copy of Windows Server 2008 standard to install on a second machine. It is fully supported to install the Terminal Services role on this second machine.
The following remote access options are available in SBS 2008:
TS Gateway
Clients running Remote Desktop Connection (RDC) 6.0 can be configured to connect to internal network resources on port 443, which most customers will have open to the internet already. This no longer requires the administrator to open RDP ports directly through the firewall.
Full details on TS Gateway can be found here: http://technet.microsoft.com/en-us/library/cc771530.aspx
Remote Web Workplace (RWW)
Clients can open an https connection to the RWW website from their web browser and access their email, connect to authorized internal machines, and connect to the internal Sharepoint website.
For more information, please see: http://technet.microsoft.com/en-us/library/cc527519.aspx
Virtual Private Network (VPN)
You can enable Routing and Remote Access (RRAS) on SBS 2008 to accept client VPN connections. Note: You cannot enable RRAS as a router or NAT firewall on server 1, due to the single network card topology requirements.
Today, we are going to discuss how to configure Non-Authoritative Accepted Domains in SBS 2008.
If you are not familiar with the concept of Accepted Domains in Exchange 2007, please refer to the following link before moving forward: http://technet.microsoft.com/en-us/library/bb124423(EXCHG.80).aspx
Three types of Accepted Domains exist in Exchange 2007. By default, SBS 2008 configures two Authoritative Accepted Domains for you; one for your .local namespace and one for your external FQDN. Authoritative domains are synonymous with enabling “This Exchange Organization is responsible for all mail delivery to this address” in Exchange 2003 recipient policies.
The other two types are Internal Relay and External Relay domains, which are Non-Authoritative domains. They must be created manually through the native Exchange interfaces if needed:
Internal Relay – Exchange accepts email for this domain, but is not the authority for all of its mail delivery, meaning that some recipients in this domain do not have mailboxes in the Exchange Organization. This is synonymous with disabling “This Exchange Organization is responsible for all mail delivery to this address” in Exchange 2003 recipient policies.
The common example that we see in SBS for this type of domain is with the use of the POP3 Connector, where a customer has configured SBS to share the same SMTP namespace as their ISP. If USERA@contoso.com has a mailbox at both the ISP and on SBS, but USERB@contoso.com only has a mailbox at the ISP, then configuring an Internal Relay accepted domain in addition to the existing SMTP connector will allow SBS 2008 mailbox users to send email to USERB.
External Relay – Used primarily on Edge Transport servers for message hygiene or smart host capabilities. Exchange accepts email for this domain, and then routes the email to the final destination using SMTP send connectors. It does not attempt any directory lookups for recipient mailboxes, as the domain is always outside of the Exchange organization. This is not the primary design intention of Exchange in SBS 2008, but this is configurable since SBS is running the Hub Transport server role.
In the following example, we are configuring SBS to share the SMTP namespace of Contoso.com, whom we are retrieving our mail from using the POP3 Connector. For detailed information regarding the POP3 Connector in SBS 2008, please visit the following SBS 2008 Technical Library link: http://technet.microsoft.com/en-us/library/cc794271.aspx
Through the use of an Internal Relay Accepted Domain, email for any unresolved recipients will be routed through the existing SMTP send connector.
If you do not configure the Accepted Domain properly, you may receive an NDR like the following:
The recipient's e-mail address was not found in the recipient's e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator
Creating Accepted Domains
There are two ways to create Accepted Domains in Exchange 2007.
Exchange Management Console:
Expand Organization Configuration > Hub Transport and click on the Accepted Domains tab.
In the right pane, under Actions, choose New Accepted Domain.
Assign it a meaningful name, enter in the domain name that you want to accept email for and choose the type of domain (Internal Relay)
At the completion screen, you can view the Powershell command that was applied in the background. Click Finish.
Exchange Management Shell:
If you want to go directly to the shell, you will need to use the New-AcceptedDomain command. For help on how to use this command, use the help new-accepteddomain –full
In the above screenshots, you can see an example of the command that is used:
New-AcceptedDomain –Name ‘POP3Connector Domain’ –DomainName ‘Contoso.com’ –DomainType ‘InternalRelay’
Email Address Considerations
To properly stamp recipients with email addresses in the shared SMTP namespace, you will need to accommodate the new Accepted Domain in your Email Address Policy. You can either edit the Windows SBS Email Address Policy to apply the new address to all recipients or create a new Email Address Policy to apply it to only specific recipients.
The advantage with a new Email Address Policy is greater control in assigning the reply to address for your recipients. When creating the policy, you can use either pre-canned filters or custom filters. For more information on recipient filters in Exchange 2007, please see: http://technet.microsoft.com/en-us/library/bb124268(EXCHG.80).aspx
Email Address Policies are different than the Recipient Policies of Exchange 2003 in that they are not used to periodically update mail enabled objects in as part of a background process. New recipients will be stamped upon creation according to the Email Address Policy to which they apply. For existing recipients, you may need to manually apply the policy to write the changes. To do this, run the following command from the Exchange Management Shell:
update-EmailAddressPolicy -Identity <EmailAddressPolicyID>
For more information on the Exchange Management Shell, visit the following: http://technet.microsoft.com/en-us/library/bb123778.aspx
[Today's post comes to us courtesy of Justin Crosby and Kim Oehmichen]
You may notice that your SBS 2008 Premium 2nd Server (Standard Server) and other servers in your domain display as Client computers in the SBS console. This can cause issues with the application of group policies and WSUS patch approvals. This issue is displayed below:
This occurs because when you join a machine to the SBS domain the SBS server automatically places the machine account into the SBSComputers OU. The client computers list is built from this OU. To correct this issue you must move your server(s) to the SBSServers OU. You can right-click the computer object and choose move as seen below:
Note: Domain controllers MUST remain in the Domain Controllers OU.
[Today's post comes to us courtesy of Kim Oehmichen]
Today’s blog will address the question why some machines (server and/or client computers) may not show up in the SBS Console. First, we will look in Active Directory Users and Computers (dsa.msc) to understand the Organizational Unit (OU) structure and how it impacts the visibility of client computers and servers in the Windows SBS console. Secondly, we will move the machines to the correct OU so that they will display in the SBS Console.
When opening SBS Console > Network > Computers, you may notice that some machines, client computers and/or servers, are not displayed.
To understand why some machines may not show in the SBS console, we have to look at the Active Directory (AD) structure. Following is an example of the typical SBS AD structure:
Notice the MyBusiness OU that is added during the SBS installation containing all SBS related OUs. The SBSComputers and SBSServers OUs determine whether or not a client computer or server is shown in the SBS console under Client Computers or Servers respectively. Only machines listed in these two OUs will be shown in the SBS console.
There are several reasons why a machine may not be in its correct OU:
NOTE: After joining a server to the domain manually, it will still be displayed as a client computer in the SBS Console. To correct this, open Active Directory Users and Computers and move the machine from the SBSComputers OU to the SBSServers OU. To move a server to the SBSServer OU follow the same steps above but select SBSServer in steps 3 and 4.