Share iT…

I have posted about this issue before, this was about this CLSID {61738644-F196-11D0-9953-00C04FD919C1}, click here to read.

Beside that error, probably after a recent update I have seen this similar error:

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{000C101C-0000-0000-C000-000000000046}
and APPID
{000C101C-0000-0000-C000-000000000046}
to the user domain\spfarm SID (S-1-5-21-1813126608-4190571182-3204100927-3160) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

The big difference with the other error is when you go to the Dcom config, security the option are all greyed out. So you need to do some additional steps:

Open registry editor (run regedit.exe), browse to Hkey_classes_root\AppID\{000C101C-0000-0000-C000-000000000046} right click and choose permissions.

Choose Advanced

Go to the Owner tab, select the Administrators (Domain\Administrators) group under Change owner to and select the replace owner on subcontainers and objects. Choose OK to close the window. You will return to the permissions window.

Select Administrators (Domain\Administrators) and set Allow Full Control permissions.

After you have done the above settings you go to Administrative Tools – Component Services. Expand Component Services, Computers, My Computer, DCOM Config. Scroll way down till you find the {000C101C-0000-0000-C000-000000000046} icon, right click and choose properties.

Go to the security tab, select customize at Launch and Activation Permissions and choose Edit…

Select the SharePoint Farm Account and set the Local Activation right.

When running the Windows Small Business Server 2011 Standard Migration Preparation Tool, keeps coming with the following popup error:

To prepare the source server for migration, you must be a member of all of the following security groups: Enterprise Admins, Schema Admins, and Domain Admins. For additional information, see the article at http://go.microsoft.com/fwlink/?LinkId=190413

But despite the account is member of all the given security groups, it won’t continue and keeps giving this message.

Solution: The message will also keeps popping up when one of the three groups is configured as the primary group. Change the primary group via Active directory users and computers to Domain Users.

After a migration to a SBS 2011 server I got the following event error message:

Event ID: 11, Source: Kerberos-Key-Distribution-Center
The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is RPCSS/Pc.domain.local (of type DS_SERVICE_PRINCIPAL_NAME). This may result in authentication failures or downgrades to NTLM. In order to prevent this from occuring remove the duplicate entries for RPCSS/Pc.domain.local in Active Directory.

This will occur when two or more computer accounts have the same service principal name registered.

Solution:
Run the following command from a command prompt:

ldifde -f check_SPN.txt -t 3268 -d “” -l servicePrincipalName -r “(servicePrincipalName=HOST/pc.domain.local*)” -p subtree

Change the pc.domain.local with the name given in the event log.

The outcome will give you two or more entries like this:

dn: CN=PC1,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC= domain,DC=local
changetype: add
servicePrincipalName: HOST/PC1
servicePrincipalName: HOST/Pc1.domain.local

dn: CN=PC2,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=domain,DC=local
changetype: add
servicePrincipalName: HOST/PC2
servicePrincipalName: HOST/Pc1.hessingnl.local

As you see both (or all) will have the same Service principal name.

In my case the additional computers with the wrong service principal name didn’t exist anymore only in Active directory users and computers, so I could just delete those computer accounts.
If the computers still exist you can remove the affected computers from your domain and re join them or use adsiedit and change the service principal name to the right value.

Additional information can be found here: kb 321044

When you have problems with or with parts of your windows small business server 2008 or 2011 and you need to troubleshoot, repair or reinstall on or more of the small business server components it is a good start to take a look at the small business server repair guide:

Windows Small Business Server 2008 Repair Guide

Windows Small Business Server 2011 Standard Repair Guide

During migration to Windows Small Business Server (SBS) 2011 you receive an error:

“Cannot connect to the domain”

“Verify that the domain name and log on credentials are correct, and then try again.”

Click the error away by pressing the OK button.

First thing to start with, make sure you entered all fields correct, if there was an error change it and try it again.

Second possibility is your network adapter need some time to load the configuration, it times out the first time, wait 30 seconds after hitting the OK button and try again.

Then third thing to try press < shift > < F10 > on the SBS 2011 this will open a command prompt, try if you can do a “ping sourceserver” and ping “sourceserver.domain.local”.

Fourth possibility the date or time differs with the source server. Make sure the date and time are set correctly on the source server. If this is all right go back to the SBS 2011 installation press or go to the command prompt if open from the previous step. At the command prompt type “date”, verify that the date is right, then type “time”, verify the time is right. You can enter the right date and / or time manually or sync it with the source server with the following commands:

“Net use * \\sourceserver\netlogon /user:domain\administrator”

The command will prompt for the administrator password you have to enter. After that enter this command to synchronize the time with the source server:

“Net time \\sourceserver /set /y”

Fifth option if time and date are right it could that the time zones differs, check the time zone on the source server and then on the SBS 2011 installation press or go to the command prompt if open from the previous step. At the command prompt type “control timedate.cpl”, make sure time zones are equal.

If these steps won’t help you could look at the setup log for errors that may point you to the right direction. Press or go to the command prompt if open from the previous step. At the command prompt enter “notepad “C:\Program Files\Windows Small Business Server\Logs\SBSSetup.log””

Most people have multiple aliases on their mailbox, with aliases on the same email domain or even with multiple domain names. But when you try to send from (send as) one of these aliases you get the following undeliverable error message returned:

“You can’t send a message on behalf of this user unless you have permission to do so. Please make sure you’re sending on behalf of the correct sender, or request the necessary permission. If the problem continues, please contact your helpdesk.”

The answer to this problem is relatively easy, by default and design this isn’t possible, but there are a couple of workarounds available:

• Create a separate mailbox and put the alias on the mailbox and configure it with send as permissions.
• Create a distribution group and put the alias on the distribution group and configure it with send as permissions.
• Create a dummy pop account in outlook and configure the alias as email address.
• There are some third party tools available that create a workaround.

Workaround 1:
Create a separate mailbox and put the alias on the mailbox and configure it with send as permissions.

First we start with removing the alias we want to send as from the original mailbox.

Now we create a new mailbox, give it a logical name, etc. and give the alias as email address.

After the account has been created we need to set Send As permissions for the newly created account. We do this via the Exchange management console by right clicking on the newly created mailbox and choose Manage Send As permissions…

Add the original user (user@domain.com) to grant Send As permission for the alias@seconddomain.com

Now you are able to send as user@domain.com also with the alias@seconddomain.com address.

We do this by using the From… field in outlook, add the alias in the from field when you want to send from the alias. When you don’t see the from field go to the options menu and choose Show From.

Best thing to do is click the From… button and select the alias mailbox from the address list.

Of course when email is send to the alias@seconddomain.com it now will be delivered to this newly created mailbox. If you would like to receive the email just as before in the same mailbox (user@domain.com), then go to the properties of the newly created alias mailbox and choose the Mail Flow Settings tab, select Delivery Options… and choose properties.

Add the original mailbox at the Forward to: field, via the Browse… button. Now all mail is forwarded to your original mailbox and all mail will be in same mailbox as before removing the alias.

Workaround 2:
Create a distribution group and put the alias on the distribution group and configure it with send as permissions.

First we start with removing the alias we want to send as from the original mailbox.

Now we create a new distribution group, give it a logical name, I always give it the name of the email alias and set the alias as email address.

Then we add the original mailbox as only member.

Now we need to set the Send As permissions for the original mailbox (user@domain.com) on the newly created distribution list. This cannot be done via the exchange management console, we have to use the exchange management shell.

This is the command syntax: Add-ADPermission “public folder name ” -ExtendedRights Send-As -user “Domain\Username”

Now you are able to send as user@domain.com also with the alias@seconddomain.com address.

We do this by using the From… field in outlook, add the alias in the from field when you want to send from the alias. When you don’t see the from field go to the options menu and choose Show From.

Best thing to do is click the From… button and select the alias distribution group from the address list.

Workaround 3:
Create a dummy pop account in outlook and configure the alias as email address.

WARNING: This option is the least recommended, because setting up this will create the posibillity to open a security hole for smtp virusses.

With this workaround we leave the email aliases as they are on the mailbox. We are going to configure a dummy / fake pop account in outlook, so no server configuration needed.
Open outlook and go to Account Settings, choose for New…, choose the email services that include Pop3, choose for manual configure server settings and choose Internet E-mail (Pop).

At Your Name: we give your name (this is the name the receiver will see), at E-mail Address we give alias@seconddomain.com, at incoming mail server, just give in something it doesn’t matter, at outgoing mail server give in your Exchange server and at username and password give in your logon credentials (the users domain account credentials).

Choose More Settings…

Make sure that you enable “My outgoing server (SMTP) requires authentication” on the Outgoing Server tab. This is needed to let you send via your exchange server, then finish the wizard.

Now you are able to send as user@domain.com also with the alias@seconddomain.com address.

We do this by using the Account button that is created after creating the dummy pop account. You just choose the email address you would like to send your email from.

Conclusion:
So you see there are a couple of workarounds available, which one is the best, there isn’t it all depends on your needs and wishes.

UPDATE: the interm fixes are not needed anymore as the fix is now included within the official 13 december 2011 update

The last days I have seen many people who are reporting they get an error message when they try to close the Exchange 2010 Management Console: “You must close all dialog boxes before you can close Exchange Management Console”.

Some research found there are many people with the same issue and that it all started after the installation of IE9. Because there is no solution yet, simply removing IE9 will help for now.

Update: Finally there has been posted a resolution by the Exchange team for fixing this problem.

First step would be installing the MS11-081 (2586448) cumulative IE security update.
Second install KB 2624899, this is a hotfix only available for this issue and should be requested by microsoft support.

Update 2: The KB 2624899 could be downloaded direct from this link here.

This is a question I see a lot and today the SBS team clarified there statement that you should install windows server 2008 R2 SP1 on your SBS 2011 server.

Quote:
“We have been receiving a few questions on whether or not Windows Server 2008 R2 SP1 can be installed on SBS 2011 and wanted to provide the definitive answer on this blog. Yes, it can and should be installed on SBS 2011 Standard. Please note that SBS 2011 Essentials already has SP1 installed out of the box.

A good rule of thumb is that if the patch or service pack is offered to your SBS server on Windows Update, it is supported to be installed on SBS. The SBS SE team reviews patches and service packs before they are offered to SBS servers.

If you download the service pack manually you may notice that it is listed as Windows Small Business Server 2011 Service Pack 1. This is normal. Windows Small Business Server 2011 Service Pack 1 == Windows Server 2008 R2 Service Pack 1.

Please be sure to back up your server before installing any update.”

Source: the official SBS blog

When you logon to a Windows Small Business Server 2008 or 2011 the SBS Console is started automatically. If you don’t want the SBS Console to start automatic you can prevent this by changing the following Task schedule.

Open Administrative Tools – Task Scheduler, go to Task Scheduler Library – Microsoft – Windows – Windows Small Business Server 2008 or 2011 Standard.

Right click Console task in the right windows and choose disable. Next time you logon the SBS Console will not be started at logon.

The C drive of your Small Business Server 2008 or 2011 is filling rapidly and when you look with a disk analyzer tool like treesize or windirstat you see that the folder C:\inetpub\logs\LogFiles\W3SVC and a 9 or 10 digit number is several or even dozens of GB. When you open one of the logfiles you see only lines with “POST /ApiRemoting30/WebService.asmx – 8530” in it.

The log file directory belongs to the WSUS Administration IIS website, this is using port 8530. But it is not WSUS that is filling these logfiles rapidly but they are filled if you let the SBS console open. Beside closing the SBS console when not needed, there are 2 option to keep the log files under control.

Option 1:
Open Administrative Tools – Internet Information Services (IIS) Manager, browse through Sites and select the WSUS Administration site and open Logging.

You have 2 options, first you can set the “maximum file size (in bytes):” option under Log file rollover to limit the maximum log file size.
Second option is to completely disable logging, by choosing “Disable” on the Actions menu on the right.

Make sure after you changed anything choose Apply on the upper right and do a iisreset.

Option 2:
The another way for controlling these logfiles is, in SBS 2011 there is by default a scheduled task configured that cleans the logfiles older than 100 days. The same task is added to SBS 2008 by installing Update Rollup 5 (KB2458094) only the default setting with this task is to delete the logfile older than 30 days.

You can change the number of days by opening Administrative Tools, Task Scheduler, go to Microsoft, Windows, Windows Small Business Server 2011 Standard, right click the WSUSLogCleaner task and choose properties. Go to the tab Actions and choose Edit…

The value given by Add arguments (optional) is the value for the number of days the logfiles will be kept. So if your logfile directory is stil really big you can decrease the number of days to something more manageable like 30 days or if this is still to much to something like 14 days.

Conclusion:
The grown of the logfiles is caused by not closing the SBS console. My logfiles have shrunken to 20% of the original size with the console open whole day. There are 2 options to control the growth of these logfiles, IIS to disable logging or maximize the logfile size or the task added in sbs 2008 rollup 5 or sbs 2011 to control the maximum number of days logfiles are kept.

Update:
If you would prevent SBS Console from startup automatically read on here