Scott Oseychik

Check it out: Public Folder “Lost and Found” functionality

scott oseychik - microsoft — Mon, 12 Oct 2015 07:06:37 GMT

Long time, no post ... been busy with Public Folders on Office 365. Take a look at out our latest addition to PF functionality: LOST_AND_FOUND

https://blogs.technet.com/b/exchange/archive/2015/10/09/introducing-public-folder-lost-and-found-functionality.aspx

--Scott

Outlook can't connect to Office 365

Scott Oseychik — Thu, 25 Jul 2013 07:58:00 GMT

Having difficulty connecting Outlook to Office 365?

Check out our easy-to-use, self-guided walkthrough troubleshooter!

Office 365 Outlook Connectivity Guided Walkthrough
https://aka.ms/outlookconnectivity

Still having issues? We have a plethora of resources available to resolve your problem:

Office 365: Outlook and mobile device connectivity troubleshooting resources
https://support.microsoft.com/kb/2757863

Finally, if your mailbox was migrated from Exchange Online ("EXO") Wave 14 to EXO Wave 15, you may need to update your Outlook profile. This is due to a change in EXO Wave 15 architecture in which we authenticate at the Transport layer (HTTPS) and no longer require RPC authentication (which will cause repeated prompting for credentials).

To fix the Outlook profile:

Start Outlook
Click "File"
Click the "Account Settings" drop-down, then select "Account Settings"
Select your e-mail address, and click "Change"
Click "More Settings"
Select the "Security" tab, and change the "Logon network security" drop-down to "Anonymous Authentication."

Props to Ryan Phillips for the EXO Wave 15 info!

Hope this helps,

-Scott

Additional Windows Live Messenger PIC/Federation IP Addresses

Scott Oseychik — Thu, 06 Dec 2012 13:04:00 GMT

Notification

In an effort to provide enhanced capacity and service reliance, Windows Live Messenger will soon be adding additional IP addresses used for PIC/Federation traffic. Some organizations have chosen to restrict this type of traffic to specific IP addresses, as referenced in Microsoft KB 897567 (https://support.microsoft.com/kb/897567). With this in mind we want to give you advanced notice of our intended change if you have configured your enterprise network in this manner.

IP addresses that are used by MSN (Windows Live)

134.170.96.0/26

157.56.187.192/26

111.221.122.192/26

For more information please reference Microsoft KB 897567, or for further assistance, please engage Microsoft Customer Support Services via https://support.microsoft.com.

The WebReady Document Viewing service has been disabled by the administrator for your organization

Scott Oseychik — Thu, 20 Sep 2012 08:11:00 GMT

UPDATE (12/20/2012):

This issue is now resolved.

Symptoms:

When using Outlook Web Access to view mail stored in a mailbox on Microsoft Office 365, and attempting to preview a Portable Document Format (PDF) attachment, the user will [currently] receive the following message:

“The WebReady Document Viewing service has been disabled by the administrator for your organization. For more information, contact your helpdesk.”

Cause:

Currently, the “WebReady Document Viewing” feature is disabled within Microsoft Office 365, as there was a security vulnerability discovered in a component (provided by a 3rd party) licensed to Microsoft.

Workaround:

Users are still be able to view PDF attachments by first downloading the attachments, then opening the file(s) locally on their computer. Users may also use the Outlook client to preview the PDF attachment from within the message itself.

Next Steps:

The Microsoft Exchange Team is working to test and deploy the corrective patches so that we can re-enable the WebReady Document Viewing feature as soon as possible.
I will update this blog post when WebReady Document Viewing is re-enabled in Microsoft Office 365.

References:

“Vulnerability Note VU#118913: Oracle Outside In contains multiple exploitable vulnerabilities”

https://www.kb.cert.org/vuls/id/118913

“Oracle Critical Patch Update Advisory - July 2012”

https://www.oracle.com/technetwork/topics/security/cpujul2012-392727.html

“Microsoft Security Advisory 2737111 and Microsoft Exchange”

https://blogs.technet.com/b/exchange/archive/2012/07/25/microsoft-security-advisory-2737111-and-microsoft-exchange.aspx

“Microsoft Security Advisory (2737111): Vulnerabilities in Microsoft Exchange and FAST Search Server 2010 for SharePoint Parsing Could Allow Remote Code Execution”

https://technet.microsoft.com/en-us/security/advisory/2737111

“More information on Security Advisory 2737111”

https://blogs.technet.com/b/srd/archive/2012/07/24/more-information-on-security-advisory-2737111.aspx

“Microsoft Security Bulletin MS12-058 – Critical: Vulnerabilities in Microsoft Exchange Server WebReady Document Viewing Could Allow Remote Code Execution (2740358)”

https://technet.microsoft.com/en-us/security/bulletin/ms12-058

"The WebReady Document Viewing service has been disabled?"

https://community.office365.com/en-us/forums/160/p/64022/247173.aspx#247173

Credits:

Amir Haque, Sr. Program Manager, Product Quality
Microsoft Exchange Sustained Engineering Team

Ensuring a successful FAST Search Server 2010 installation

Scott Oseychik — Wed, 29 Sep 2010 13:23:00 GMT

While we get this information cleaned-up, fully-documented, and stored in a more “formal” location (e.g. https://support.microsoft.com), here are some initial Best Practices the FAST Technical Support and Escalation Teams have been successful with in terms of resolving various FAST Search Server 2010 issues specific to various networking issues.

1. Disable TCP Chimney:

https://support.microsoft.com/kb/951037

“Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008”

To disable TCP Chimney Offload, follow these steps:

Use administrative credentials to open a command prompt.

At the command prompt, type the following command, and then press ENTER:

netsh int tcp set global chimney=disabled

References:

https://support.microsoft.com/kb/945977

“Some problems occur after installing Windows Server 2003 SP2”

Note: While the above article discusses Windows Server 2003 SP2, the TCP Chimney / Scalable Networking Pack information is still applicable to Windows Server 2008 SP2/R2.

https://support.microsoft.com/kb/942861

“Error message when an application connects to SQL Server on a server that is running Windows Server 2003: ‘General Network error,’ ‘Communication link failure,’ or ‘A transport-level error’ ”

https://blogs.msdn.com/b/scottos/archive/2010/09/10/leave-the-chimney-for-santa-claus-not-for-fast-search-server-2010.aspx

2. Ensure all of the “offload” settings on the network adapter’s driver are set to Disabled:

3. Validate that IPSEC is behaving properly:

https://blogs.msdn.com/b/scottos/archive/2010/07/16/we-need-to-talk-aka-it-s-not-me-it-s-you.aspx

Leave the chimney for Santa Claus, not for FAST Search Server 2010

Scott Oseychik — Fri, 10 Sep 2010 06:29:00 GMT

Recently, the FAST Search Escalation Team has begun to see customers encountering a higher-than-expected rate of post-installation configuration/deployment failures due to IPSEC problems. As a follow-up to my previous post (see "We need to talk"), I wanted to call out a very subtle but important point noted in https://support.microsoft.com/kb/951037, "Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008."

As noted in the article, IPSEC is not compatible with TCP/IP offloading, therefore, we strongly recommend FAST Search Server 2010 customers disable all TCP/IP offloading functionality, both in the Registry (where the TCP/IP parameters are stored), as well as on the properties of the Network Adapter itself.

From KB 951037:

How TCP Chimney Offload coexists with other programs and services

When the TCP Chimney Offload technology offloads TCP/IP processing for a given TCP connection to a dedicated network adapter, it must coexist with other programs or services that rely on lower layer services in the networking subsystem. The following table shows how TCP Chimney Offload coexists with other programs and services.

Program or service	Works together with TCP Chimney Offload	Expected behavior when both the service and TCP Chimney Offload are enabled
Windows Firewall	Yes	If the firewall is configured to allow for a given TCP connection, the TCP/IP stack will offload that TCP connection to the network adapter.
Third-party firewall	Implementation-specific	Some firewall vendors have decided to implement their product in such a way that TCP Chimney Offload can be used while the firewall service is running. Refer to the firewall documentation to find out whether the product you are using supports TCP Chimney Offload.
Internet Protocol security (IPsec) policy	No	If the system has an IPsec policy applied, the TCP/IP stack will not try to offload any TCP connections. This lets the IPsec layer inspect every packet to provide the desired security.
Network Adapter teaming service (This service is also known as the Load Balancing and Failover service. It is usually provided by an OEM.)	Implementation-specific	Some OEMs have decided to implement their network adapter teaming solutions so that they coexist with TCP Chimney Offload. See the network adapter teaming service documentation to determine whether you can use TCP Chimney offload together with this service.
Windows Virtualization (Hyper-V technology)	No	If you are using the Microsoft Hyper-V technology to run virtual machines, no operating system will take advantage of TCP Chimney offload.
Network monitoring tools, such as Network Monitor and Wireshark	Implementation-specific	Some network monitoring tools may coexist with TCP Chimney but may not monitor offloaded connections.
Network Load Balancing (NLB) service	No	If you configure the NLB service on a server, the TCP/IP stack does not offload TCP connections.
Cluster service	Yes	However, note that TCP connections using the Network Fault Tolerant driver (NetFT.sys) will not be offloaded. NetFT is used for fault-tolerant inter-node cluster communication.
Network Address Translation (NAT) service (also known as the Internet Connection Sharing service)	No	If this service is installed and running, the TCP/IP stack does not offload connections.

We need to talk (aka: “It’s not me, it’s you”) ...

Scott Oseychik — Fri, 16 Jul 2010 13:33:11 GMT

Issue:

After installing an Administrative node of FAST Search Server 2010, additional Non-Administrative FAST Search Server 2010 nodes cannot communicate with the Admin node. Subsequently, the non-admin nodes to fail download the deployment.xml, and as such, fail to finish configuration successfully.

What you can expect to see:

When running the psconfig.ps1 script on the non-admin nodes via PowerShell, you may see a failure similar to the following:

Please wait while Windows configures FAST Search Server for SharePoint. Configuration may take several minutes...

An error occurred while configuring IPSec - Could not connect to the admin node.

This may be because of,

1. Invalid admin node name

2. Invalid baseport. Baseport of admin node and non-admin node must be same

3. Admin node is not up and running

4. Missing IPSec rules on admin node. If you added this host to the deployment.xml after running this script on the admin node, you need to rerun the IPSec cmdlet on the admin node

See C:\Install\FAST\log\fast-install.log for more details.

This is also evident if you simply attempt to run the Set-FASTSearchIPSec PowerShell cmdlet:

2010-07-15 04:03:19.170Z Verbose [15] SetIPSec - no.fast.middleware.SystemException: Unable to connect to the remote server ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 157.54.158.87:13390

at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)

at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)

--- End of inner exception stack trace ---

at System.Net.HttpWebRequest.GetRequestStream()

at no.fast.middleware.ConnectionManager.ExecuteMethod(HttpWebRequest request, MemoryStream dataStream)

at no.fast.dsinterfaces.nameservice.NameserverStub.Resolve(String Name, String InterfaceType, String Version)

--- End of inner exception stack trace ---

at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Middleware.MiddlewareOperations.DownloadDeploymentConfig(String localhost, String nameserverhost, String middleware_port, String fileName)

at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Cmdlets.SetIPSecCommand.CreateNonAdminRules(IHostConfig hostConfig)

at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Cmdlets.SetIPSecCommand.ProcessRecord()

Root Cause (Summary):

The non-admin node(s) attempt to communicate to the admin node via port 13390, which is secured via IPSEC. If the Kerberos session encounters a failure, the IPSEC connection is never established, and the socket will not be opened.

How to Troubleshoot:

1. In these scenarios, we use the “Microsoft IPSEC Diagnostic Tool” (from https://support.microsoft.com/kb/943862) to gather additional diagnostic data specific to the IPSEC failures.

2. Once the data has been collected, open the wfpdiag.txt file, search for “ERROR_IPSEC_IKE_AUTH_FAIL,” and then you should see data similar to the following:

[2]01C0.15D4::07/15/2010-16:38:22.626 [user] |146.27.92.41|Peer failed with Windows error 13801(ERROR_IPSEC_IKE_AUTH_FAIL)

[2]01C0.15D4::07/15/2010-16:38:22.626 [ikeext] 1137|146.27.92.41|ProcessNotifyData: mmSa 0000000002F14600 cookie 71ddc30c state 2 messId 0

[3]01C0.15D4::07/15/2010-16:38:22.643 [ikeext] 1137|146.27.92.41|IKE diagnostic event:

Event Header:

Timestamp: 1601-01-01T00:00:00.000Z

Flags: 0x00000106

Local address field set

Remote address field set

IP version field set

IP version: IPv4

IP protocol: 0

Local address: 146.27.92.39

Remote address: 146.27.92.41

Local Port: 0

Remote Port: 0

Application ID:

User SID:

Failure type: IKE/Authip Main Mode Failure

Type specific info:

Failure error code:0x000035e9

IKE authentication credentials are unacceptable

Failure point: Remote

Flags: 0x00000002

Multiple MM failures present

Keying module type: Authip

MM State: Second roundtrip (SSPI) packet sent

MM SA role: Responder

MM auth method: Unknown

Cert hash:

0000000000000000000000000000000000000000

MM ID: 0x0000000000000471

MM Filter ID: 0x000000000004bfc3

[3]01C0.15D4::07/15/2010-16:38:22.644 [ikeext] 1137|146.27.92.41|IKE diagnostic event:

Event Header:

Timestamp: 1601-01-01T00:00:00.000Z

Flags: 0x00000106

Local address field set

Remote address field set

IP version field set

IP version: IPv4

IP protocol: 0

Local address: 146.27.92.39

Remote address: 146.27.92.41

Local Port: 0

Remote Port: 0

Application ID:

User SID:

Failure type: IKE/Authip Main Mode Failure

Type specific info:

Failure error code:0x000035ec

General processing error

Failure point: Local

Flags: 0x00000002

Multiple MM failures present

Keying module type: Authip

MM State: Second roundtrip (SSPI) packet sent

MM SA role: Responder

MM auth method: Kerberos

Cert hash:

0000000000000000000000000000000000000000

MM ID: 0x0000000000000471

MM Filter ID: 0x000000000004bfc3

[2]01C0.15D4::07/15/2010-16:38:22.644 [ikeext] 1137|146.27.92.41|Cleaning up mmSa: 0000000002F14600. Error 13801(ERROR_IPSEC_IKE_AUTH_FAIL)

Root Cause (Details):

After reviewing the data above, we can clearly see a breakdown in the IPSEC conversation. This is primarily caused by one (or both) of the following tweaks:

· A Group Policy setting that forces the Kerberos conversation to take place entirely over UDP (“MaxPacketSize”)

· A Group Policy setting that restricts the Maximum Token Size (“MaxTokenSize”)

To verify this, open an Administrative Command Prompt, and run “GPRESULT -V” (no quotes), and you should see an entry similar to the following:

GPO: Default Domain Policy

KeyName: SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize

Value: 160, 134, 1, 0

State: Enabled

This indicates that the Default Domain Policy is modifying the default settings for the MaxTokenSize, and subsequently is interfering with our ability to successfully establish a connection via IPSEC.

Resolution:

You may pursue the following options to resolve this issue:

· Exclude the FAST Search Server 2010 machines from having this setting applied to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize

· The FAST Server Administrators may potentially override the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize setting manually in the Registry (to a value of 0x0000FFFF), and subsequently lock it down such that future Group Policy applications do not overwrite this setting

Please refer to https://support.microsoft.com/kb/327825, “New resolution for problems with Kerberos authentication when users belong to many groups” for further information regarding the MaxTokenSize registry value.

How to extract, count, and sort strings pulled from a managed dump file

Scott Oseychik — Wed, 12 May 2010 12:34:00 GMT

If these steps look familiar, they’re based off a post I wrote a few years back for parsing Exchange transaction logs. Who knew 1) they’d still be relevant, 2) I’d still resort to such hacky means, and 3) others may actually find value in this ...

1. Download the "Unix for Win32" utilities from https://downloads.sourceforge.net/unxutils/UnxUtils.zip?modtime=1172730504&big_mirror=0

2. Extract all files from the UnxUtils\usr\local\wbin subsirectory to C:\Unix

3. Download strings.exe from https://www.microsoft.com/technet/sysinternals/Miscellaneous/Strings.mspx, and place strings.exe into C:\Unix

4. Make a C:\TMP directory (The Win32 versions of Unix tools need the Windows equivalent of the /tmp directory on Unix)

5. Download the sosex.dll Windbg extension from https://www.stevestechspot.com/SOSEXV2NowAvailable.aspx; save sosex.dll to your directory where Windbg.exe resides

6. In Windbg, open the .dmp file, '!load sosex.dll', do '.logopen managed-strings.log', then do '!sosex.strings'

Opened log file 'c:\drop\customers\internal\managed-strings.log'

0:000> !sosex.strings

Address Gen Value

---------------------------------------

7f2290c8 0

7f229108 0

7f22911c 0 Filters/IncludeExtensions

7f229160 0 Filters/IncludeExtensions

7f229394 0 true

7f22c778 0

7f22c7d4 0 true

7f22c7f0 0 Filters/CrawlWebApplication

7f22c838 0 Filters/CrawlWebApplication

...

7. Once the sosex.dll extension completes, do '.logclose'

8. In your filename.log, you'll see output similar to the following:

0:000> !sosex.strings

Address Gen Value

---------------------------------------

7f2290c8 0

7f229108 0

7f22911c 0 Filters/IncludeExtensions

7f229160 0 Filters/IncludeExtensions

7f229394 0 true

7f22c778 0

7f22c7d4 0 true

7f22c7f0 0 Filters/CrawlWebApplication

7f22c838 0 Filters/CrawlWebApplication

7f22cd6c 0

7f230150 0

7f230190 0

7f2301a4 0 Filters/ExcludeListTypes

7f2301e8 0 Filters/ExcludeListTypes

7f23041c 0 true

7f233800 0

7f23385c 0 true

7f233878 0 Filters/IndexItemView

7f2338b4 0 Filters/IndexItemView

7f233d9c 0 logs

7f237180 0

7f2371dc 0 logs

7f2371f8 0 ConnectorExecution/WorkFolder

7f237244 0 ConnectorExecution/WorkFolder

9. Open an elevated command prompt, change to your C:\Unix directory, and then issue the following command:

For example:

...

202564 Database/DataSource

202564 Database/InitialCatalog

202564 Database/Password

202564 Database/PersistenceHandlerDB

202564 Database/PurgeAtStart

202564 Database/RetryPeriodWhenDBIsDown

202564 Database/TableNamePrefix

202564 Database/Username

202564 ESPSubmit/Collection

202564 Filters/CrawlWebApplication

202564 id;listtitle;listdescription;listid;listitemcount;modifiedby;createdby;id;name;created

202564 Logging/FileMode

202564 Logging/LogFile

202564 Logging/LogLevel

202564 Logging/LogServer

202564 espconn-1:16100

202564 teamsites

202565 50

202565 5000

202565 548513

202565 AUTOFLUSHFILE

202565 sql08ma1-1.eelab.fastesc.com

202565 FAST_SEARCH_QA

202565 logs

202565 MOSSConnector.log

202565 my_fast_search

202565 prod

202565 SqlServer

202566 5

202566 FAST_Hello_QA

202566 kerberos

202569 TRACE

202572 1

405130 3600

2025650 true

Communicator 2007 R2 fails to open new window when double-clicking a Contact

Scott Oseychik — Fri, 25 Sep 2009 09:55:00 GMT

Summary:

When using Microsoft Office Communicator 2007 R2, double-clicking a Contact fails to launch a new conversation window. However, you are still able to right-click a Contact, and start an IM session by selecting “Send an Instant Message.”

Cause:

When double-clicking a Contact, OC 2007 R2 uses XML to initialize a new conversation window, and we’re finding several customers who have incompatible and/or legacy builds of MSXML.DLL that are encountering these failures.

Example Callstack:

ChildEBP RetAddr

0006f98c 00475448 communicator!CDUIBase::InitializeFromXML

0006f9c4 00475309 communicator!CRosterContactView::CreateInstance+0x8b

0006f9e4 004dd544 communicator!CContactManager::CreateElement+0xeb

0006f9fc 004dd563 communicator!VirtualListView::CreateElement+0x30

0006fa14 004dc3af communicator!VirtualListView::FillVisibleLink+0x122

0006fa48 004d57db communicator!VirtualListView::FillViewWithoutRefresh+0xbd

0006fa80 004f347b communicator!VirtualListView::FillView+0xa9

0006fa90 004f3489 communicator!VirtualListView::OnThaw+0x30

0006fa98 00482d69 communicator!Freezable::Thaw+0xf

0006facc 0046cd9c communicator!CContactGroupItemBase::AddItemAtIndex+0xba

0006fadc 0046d13e communicator!CContactGroupItemBase::AddItemLast+0x10

0006fb08 0046d0e3 communicator!CContactManager::AddContact+0x57

0006fb20 004b0d40 communicator!CRosterListView::OnParticipantAdded+0x3f

0006fb60 0046d2b1 communicator!CRosterListView::SetContext+0x10a

0006fb94 0046cf79 communicator!CDUIConversationFrame::InitializeChildren+0xd0

0006fbe0 00479f8b communicator!CDUIConversationFrame::Initialize+0x234

0006fc34 0045cba0 communicator!CDUIConversationFrame::EnsureConversationWindow+0xe3

0006fc60 0045bf6a communicator!CDUIConversationFrame::CreateNewWindow+0x76

0006fcac 0045cb89 communicator!CDUIConversationFrame::FindOrCreateTwoPartyConversationWindow+0xde

0006fcd0 00427ba3 communicator!ConvUI_FindOrCreateTwoPartyConversationWindow+0x1e

0006fd68 0055d909 communicator!CSelectedContacts::StartActionWithSelectedContacts+0x1a3

0006fd88 7e418734 communicator!CSelectedContacts::WndProc+0x4e

0006fdb4 7e418816 user32!InternalCallWinProc+0x28

0006fe1c 7e4189cd user32!UserCallWinProcCheckWow+0x150

0006fe7c 7e418a10 user32!DispatchMessageWorker+0x306

0006fe8c 00505efb user32!DispatchMessageW+0xf

0006fed8 005079ac communicator!COcApp::RunMessageLoop+0xa1

0006fee8 00507b85 communicator!ATL::CAtlExeModuleT::Run+0x1e

0006ff18 00507a9c communicator!COcApp::RunApp+0xed

0006ff30 00507a05 communicator!WinMain+0x7e

0006ffc0 7c817067 communicator!__tmainCRTStartup+0x140

0006fff0 00000000 kernel32!BaseProcessStart+0x23

Example incompatible/legacy version of MSXML.DLL:

0:008> lmvm msxml

start end module name

71130000 711b3000 msxml (export symbols) msxml.dll

Loaded symbol image file: msxml.dll

Image path: c:\windows\system\msxml.dll

Image name: msxml.dll

Timestamp: Fri Nov 05 13:10:21 1999 (38230F7D)

CheckSum: 000850E5

ImageSize: 00083000

File version: 5.0.2919.6303

Product version: 5.0.2919.6303

File flags: 0 (Mask 3F)

File OS: 40004 NT Win32

File type: 2.0 Dll

File date: 00000000.00000000

Translations: 0409.04b0

CompanyName: Microsoft Corporation

ProductName: Microsoft(R) Windows (R) 2000 Operating System

InternalName: MsXML.dll

OriginalFilename: MsXML.dll

ProductVersion: 5.00.2919.6303

FileVersion: 5.00.2919.6303

FileDescription: XML OM for Win32

Resolution:

To resolve this issue, please install XML Version 6.0 and XML Version 3.0 SP7.

Microsoft Core XML Services (MSXML) 6.0

https://www.microsoft.com/downloads/details.aspx?FamilyID=993C0BCF-3BCF-4009-BE21-27E85E1857B1&displaylang=en

Microsoft XML Parser (MSXML) 3.0 Service Pack 7 (SP7)

https://www.microsoft.com/downloads/details.aspx?familyid=28494391-052b-42ff-9674-f752bdca9582&displaylang=en

Huge credit goes to Dieter Eckstein for this solution!

Installation of OCS 2007 R2 Hotfix Package 969834 may fail if SQL settings have been changed

Scott Oseychik — Fri, 21 Aug 2009 13:06:00 GMT

Summary:

Installation of the OCS 2007 R2 “Backend” hotfix package (https://support.microsoft.com/kb/969834) may fail, and unfortunately, the error message presented to the Administrator isn’t entirely clear as to what the root cause is.

More Information:

If you find that installation of OCS2009-DBUpgrade.msi is failing against your backend SQL RTC databases, locate and open the resulting QFE_DBSetup.log file. The following output is generated in the QFE_DBSetup.log, and note the highlighted entry below:

/PoolName: specified FQDN. Assuming /PoolName:R2POOLNAME.contoso.com

Attempting to discover BackEnd SQL instance from AD.

LDAP Query (ConfigurationNamingContext): LDAP://CN=Configuration,DC=contoso,DC=com;((&(objectClass=msRTCSIP-Pool)(msRTCSIP-PoolType:1.2.840.113556.1.4.803:=2)(msRTCSIP-PoolDisplayName=R2POOLNAME.contoso.com)));distinguishedName,msRTCSIP-BackendServer;subTree

Backend Server Instance List: R2BESQL

Backend Server Instance for Pool 'R2POOLNAME.contoso.com' is 'R2BESQL'

Discovered SqlServer R2BESQL

Updating EE server database stored procedures. This will take a while ...

cscript dbsetup.wsf /Verbose /Role:ee /SqlServer:R2BESQL

Microsoft (R) Windows Script Host Version 5.6

Installed SQL Server 2005 Backward Compatibility version is 8.05.2004

Connecting to SQL Server on R2BESQL

Error attempting to validate the SQL server: reconfigure statement failed. This SQL instance has pending configuration changes that need to be resolved before installation can continue.

[Microsoft][ODBC SQL Server Driver][SQL Server]Ad hoc update to system catalogs is not supported.

Workaround:

1. In SQL Server Management Studio, run the following SQL statement:

sp_configure 'allow updates', '0'

RECONFIGURE WITH OVERRIDE

2. Re-run OCS2009-DBUpgrade.msi

Credit:

Many thanks to Santhosh K for finding this needle in the haystack while I was busy waking up half of the RTC Dev Team. :-)