Your IT, our business


Skip Navigation Links
Home
About Us
IT Support
Training
Consultancy
Hardware Sales
Authoring
Software Licensing
Case Studies
Blog


Case Studies

Friends International

Kensington Group

Infobasis

Oxford Tutorial College

ITEX

Microsoft Press

Contact Us

C7 Solutions Team Blog

 

Latest News



Microsoft Certified Partner

Microsoft Small Business Specialist

Wednesday, January 28, 2009

SBS and WEBS 2008 Backup Fails to Backup Exchange Server

The following errors are reported in the Event Log Windows Logs/Application when you run the built-in backup that is part of Small Business Server 2008 (SBS) or Windows Essential Business Server 2008 (WEBS):

Event ID 565 - Consistency check for component StorageGroup-GUID\'Microsoft Exchange Server\Microsoft Information Store\SERVER' failed. Application 'Exchange' will not be avaliable in the backup done at time 'date time'

The Event Viewer log at Application and Services Logs/Microsoft/Windows/Backup/Operational shows that everything completed fine but the Windows Server Backup administrative tool says backup completed with warnings. Double-clicking the backup record shows:

Application will not be available for recovery from this backup. Consistency
check failed for component Microsoft Exchange Server\Microsoft Information
Store\Server-Name\Store-GUID

This seems to be related to having enabled Local Continous Replication (LCR) on the Exchange mailbox database. This is unfortunate as LCR is such a useful tool in recovery for Exchange Servers that I would want to enable it as a matter of course, and spec my SBS servers to have enough disk space to store LCR copies. Note that the actual Exchange databases and log files are backed up as part of the volume backup, just not as part of the application aware backup and that might result in invalid restores as the volume level backup is not Exchange aware.

Please Microsoft, will you make the VSS backup for Exchange 2007 that is included in SBS and WEBS LCR aware. Thanks.

Labels: , , , ,

permalink posted by Brian Reid : 2:05 PM 0 comments

Friday, January 16, 2009

Remote Web Workplace not operating in SBS 2008 or EBS 2008

If when you log into Remote Web Workplace on Small Business Server 2008 or Essential Business Server 2008 as a non-administrator user you get the following error messages:

Cannot connect to the Remote Web Workplace site. To continue, contact your network administrator.

Event Viewer/Application Log/ASP.NET 2 Warning: Event ID 1309
ArgumentOutOfRangeException "Index was out of range. Must be non-negative and less than the size of the collection." Request URL: https://server:443/remote/menu.aspx

You need to do the following to fix this error. On the server you need to modify the permissions of the RWWConfig.xml file. This file is located in "C:\Program Files\Windows Small Business Server\Data" or "C:\Program Files\Windows Essential Business Server\Data" depending upon the product that you are running.

  1. Ensure the permissions on the above file are
    Authenticated Users - Read (not inherited)
    NETWORK SERVICE - Read (not inherited)
    SYSTEM - Full Control (inherited from parent folder)
    Administrators - Full Control (inherited from parent folder)
  2. Make sure the Authenticated Users group is a member of the Pre-Windows 2000 Compatible Access group.
  3. Run iisreset from the command line on the server
  4. Attempt the login again, but first close any copy of Internet Explorer that was running (or attempting to run) RWW.

Labels: , ,

permalink posted by Brian Reid : 10:39 AM 0 comments

Friday, January 09, 2009

CRM 3.0 Disaster Recovery

Updated 9 Jan 2009 as I needed to repeat these steps again, and so have
clarified them a bit!


I am in the process of performing a CRM restore, when I came across this cryptic message: "One or more Microsoft CRM groups do not exist".


I am restoring into a new Active Directory so the groups do not exist, but the installer does not create them or tell me what they should be (in full). It tells me via help that the groups need to be called:


  • PrivUserGroup
  • ReportingGroup
  • SQLAccessGroup
  • UserGroup

But what it misses out is that these groups are to be suffixed with the Organisation GUID for the previous installation (who's databases I have, and am restoring CRM using).

The organisation GUID is stored in the database, and you need to run the following SQL query on the MSCRM SQL database to get the answer:

  • SELECT TOP 1 OrganizationID, Name FROM organizationbase

Also ensure that during the reinstall of CRM 3.0, you set the Organisation name to that which is returned from the database and use the same product key as before. The product key can be obtained using "SELECT licensekey FROM license"

You also need to set the buildnumber in the BuildVersion table to 0 and delete any mentioned Qfe values, noting them down so that you can install these hotfixes later on.

Finally you need to change the GUID in OrganisationBase for each of the four groups above to the new objectGUID value for each group that you have just created. Using adsiedit.msc (part of the Windows Support Tools on the Windows Server installation CD-ROM) view the objectGUID value for each in hex. Then copy the value to notepad and reverse the first four groups of characters, reverse the next two groups of characters, reverse the third group of two and copy and paste the fourth group of two and the final group of six (the last two groups are not reversed). Note that you do not reverse each pair of characters individually, but treat each pair as a group and reverse the groups as shown below. Put curly braces on the new GUID and paste into SQL Enterprise Manager (or if using SQL 2005 run a script as shown below.

For example:

  • objectGUID=0x 1x 2x 3x 4x 5x 6x 7x 8x 9x Ax Bx Cx Dx Ex Fx

becomes:

  • GUID in database={3x2x1x0x-5x4x-7x6x-8x9x-AxBxCxDxExFx}

  • SQL 2005 Script (no {} in GUIDs here though): UPDATE OrganizationBase SET UserGroupID='GUID', PrivilegeUserGroupID='GUID', ReportingGroupID='GUID', SQLAccessGroupID='GUID'

During the installation you need to ensure that the installation user does not exist in SystemUserBase. To do this find the current installation user in the DomainName column and rename this users domain name (for example DOMAIN\administrator becomes DOMAIN\xxAdministrator). A new user will then be created during this installation.

Finally once installed, start the Deployment Manager tool and reassociate all the users with the newly created user in the new Active Directory. Restoring CRM into an existing AD is much simpler - just the Organisation Name and Product Key need to be retreived.

permalink posted by Brian Reid : 1:47 PM 3 comments

Archive

March 2005 July 2005 February 2006 May 2006 November 2006 March 2007 May 2007 June 2007 August 2007 April 2008 May 2008 June 2008 September 2008 October 2008 November 2008 January 2009 February 2009 March 2009