Vlada's Blog

WSS 3.0 0x8007005 Installation Error

2009-09-15T15:10:00Z

Scenario:

Working on a client site recently, I have installed Windows Sharepoint Services 3.0 in a stand-alone server mode. Everything worked fine until I've opened Central Administration Site and realized that the person who gave me access to the server logged me on as a local server administrator.

Since the server was member of a company domain, I decided to reinstall WSS in order to avoid future problems (actually I remember that I read somewhere that it is not a good practice doing WSS installation as a local server Administrator).

So, I uninstalled WSS 3.0, manually deleted Sharepoint Central Administration Site web site (have no idea why it wasn't deleted automatically), restarted server, logged on as a domain user which was member of local Administrators group, and started setup again.

Everything worked fine, until step 8 of 10 of "Sharepoint Products and Technologies Wizard"....In a blink of an eye I saw the status message "Error creating Sample Site" or something similar, and then window with this message appeared:

HRESULT: 0x80070005 E_ACCESSDENIED

Reason:

I had no time and will to research further "why and where"....but even after complete remove and reinstall, WSS 3.0 was still keeping information that the Primary administrator of a first sample site collection is SERVER\Administrator, from the first installation, instead of the DOMAIN\WSSadmin who did the most recent installation.

Solution:

A lot of Googling pointed me to problem with WMI DCOM configuration and lack of permission for the local ASPNET account....not in my case...;)

Since the Central Administration Site was fully functional, I've accessed Application Management Section, removed SERVER\Administrator from Primary admin, added domain user account DOMAIN\WSSadmin as the Primary admin and re-run Sharepoint Technologies Wizard.

This time everything worked fine.

Conclusions/Advices:

Create domain user account for WSS admin, make it member of server's local Administrators group and use it for WSS installation and initial administration.

KERBEROS error 4 (Part II)

2009-09-03T19:48:00Z

Scenario:

For an unknown reason Domain Controller in a branch office stopped to replicate Active Directory data with Domain Controllers in the main site.

DCDIAG showed this:

[DC1] DsBindWithSpnEx() failed with error -2146893022,

The target principal name is incorrect..

Warning: DC1 is the Schema Owner, but is not responding to DS RPC Bind.

[DC1] LDAP bind failed with error 8341,

A directory service error has occurred..

Warning: DC1 is the Schema Owner, but is not responding to LDAP Bind.

Warning: DC1 is the Domain Owner, but is not responding to DS RPC Bind.

Warning: DC1 is the Domain Owner, but is not responding to LDAP Bind.

DC1 is a Domain Controller in the main site with all FSMO roles.

Event viewer kept logging Error from source Kerberos and EventID 4 :

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/.... The target name used was..... This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server.

Commonly, this is due to identically named machine account in the target realm (...), and the client realm.

And at the end my favorite sentence:

Please contact your system administrator.

Have they ever considered a very small possibility that the one who is reading this message in the System log of a Domain Controller might be actually "our System Administrator" ...;))

Screenshot from Event Viewer:

Reason:

Yet another classic problem, solved many times never documented it before...have no idea why, it just happens from time to time.

Solution:

If you want to solve this problem quickly run:

dcpromo /forceremoval on branch office DC, restart server, and run dcpromo again.

Almost all Google results on this subjects points to NETDOM and reset computer account. Never worked for me.

Conclusion/Advice:

If you have branch offices connected with slow and unreliable links and a Domain Controller in it, bookmark this page.....this can happen to you too....;)

File Server Migration Story

2009-06-26T16:09:00Z

Scenario:

On of my clients have recently bought a new server box and an external storage system, and my task was to migrate all files and folders to the new system while interrupting users at least as possible (damn users…;).

Requirements:

1) The old file server (SERVER1) had 4 physical disks partitioned as D,E,F and G with lots of shared folders and defined NTFS permissions, and new storage system was visible as a single drive S from the new server (SERVER2).

2) The old server (SERVER1) must not be removed from production because it had hardware and software which was controlling external tape backup device system.

Steps:

1) First step was to migrate files, folders, shares and NTFS permissions from multiple drives on SERVER1 to a single drive on SERVER2. Tasks included:

· Stopped Server service on SERVER1 so it was not anymore accessible for file sharing to clients.

· Using software from the tape manufacturer backed up all folders onto tapes.

· Joined the new server (SERVER2) to domain and restored backup on a drive S (RAID-5 on storage system), while preserving NTFS permissions.

· Exported HKEY_LOCAL_MACHINE\SYSTEM\Current Control Set\Services\LanmanServer\Shares from SERVER1 and imported it into the same place on SERVER2.

· Corrected manually all references for D,E, F and G drives to point to letter S (actually I delegated this task to one of my junior squad member...;).

· Restarted Server service on SERVER2 and checked that all shares are correctly recreated.

2) Second step was to redirect clients to SERVER2 without modifying paths in client's mapped folders and shortcuts. Tasks included:

· Modified SERVER1 "Local Area Connection" properties and cleared "Register this connection's address in DNS" and removed IP address of WINS server in TCP/IP properties.

· Created DNS alias for SERVER1 name to point to the IP address of SERVER2.

· Deleted WINS record for SERVER1 and created a new static unique mapping with the IP address of SERVER2.

Problems:

System error 52 has occurred.
A duplicate name exists on the network.

Lucky me, I was already familiar with this one from one of my previous projects, and remembered that it has to do with something called "strict name checking" in Windows 2003 server. And so Google pointed me to Microsoft KB article:

http://support.microsoft.com/kb/281308

After adding DisableStrictNameChecking value under HKEY_LOCAL_MACHINE\System\Current Control Set\Services\LanmanServer\Parameters, setting it to 1 and restarting the server .... new error appeared:

System error 5
Access is denied.

This was new, even to me....;))

Reason:

I guess that KB 281308 assumes that there is no other server in production called like given alias or that the old file server is permanently offline. In this scenario SERVER1 was still online and had account in Active Directory.

Solution:

After I renamed SERVER1 into something different, like SERVER1OLD and restarted it everything worked fine....:)

Internet Explorer 8.0 Beta 2 and Exchange 2003 OWA Problem

2008-10-21T19:45:00Z

Scenario:

An advanced user from one of the company with which I have maintenance contract called me yesterday, asking for an advice. He was complaining that he cannot access OWA anymore since he has upgraded his Internet Explorer from version 7.0 to version 8.0 Beta 2. He was using Vista, and explained that he read in a local PC magazine that IE8 B2 is very stable version and listened to author’s advice to upgrade his “old” version of IE 7.0 to version 8.0 as soon as possible….;)…nice….!

Everything worked fine, except that he couldn’t access OWA anymore. Logon screen was appearing, but upon successful logon IE8 kept crashing.

Reason:

Have no idea…but Google showed me that I am not the first one complaining, there were few users out there with similar problem.

Solution:

So, I adviced him to uninstall IE 8.0. But…not long after, he called me again saying that there is no Internet Explorer 8.0 or something similar under Vista’s Control Panel “Program and Features” ?

Well, of course...;), because Internet Explorer 8.0 is not a “Program” anymore, it is now update to Windows, so I told him to click on “View installed updates” on the top left corner of Vista’s Control Panel “Program and Features”, and uninstall it from there….:)

Conclusions/Advices:

1. Wait for the final release of Internet Explorer 8.0, especially in production environments.

2. Don’t believe in articles you read in local PC magazines...;)

Exchange 2007 ‘Sender Reputation Filter’ Story

2008-10-16T19:34:00Z

Prologue:

“Sender Reputation is anti-spam functionality that is enabled on computers that have the Microsoft Exchange Server 2007 Edge Transport server role installed to block messages according to many characteristics of the sender. Sender reputation relies on persisted data about the sender to determine what action, if any, to take on an inbound message. “

Microsoft , 2006.

Scenario:

One of my old clients called me recently, saying that they have bought some new server boxes and, beside other changes, asking for best advice how to improve their e-mail infrastructure from both, performance and security aspects. They were using Exchange 2003 with GFI Mail Security Antivirus and GFI Mail Essentials Antispam protection that I have installed some time ago. They also have dedicated ISA server for proxy/firewall functionality:

Exchange 2003 (+GFI) <--------------------> ISA <----------------> INTERNET

My advice to them was to migrate to Exchange 2007, and also to implement a Windows 2003 Web Edition Server in DMZ to act as a SMTP relay server, with GFI Mail Security and GFI Mail Essentials installed on that server. Since they were already paying for Exchange Enterprise CALs in their licensing program I suggested Forefront Security on internal Exchange (with 9 Antivirus and 2 Antispam engines they should be pretty safe….;)):

Exchange 2007 (+Forefront) <-------> ISA <------> IIS SMTP relay (+GFI) <----> INTERNET

I’ve installed GFI modules on Relay server and configured Antispam engine to append string “[SPAM]” in subject line for every message that is likely to be spam. Then, I created Transport Rule on Exchange server to increase SCL level for this type of messages to 9 so that they always end in user’s Outlook Junk E-mail folder.
I‘ve tested this configuration by sending a few legitimate mails and also few with “sex $$$ Viagra” in subject and/or body, and everything worked perfectly (not a good sign….;))

Problem:

Not very long after, some of the employees said that their clients are complaining that all messages sent to them are rejected by our mail server.
From Relay server, I've succesfuly telneted to port 25 on internal Exchange server, and typed:

HELO test.test.net
Mail from:test@test.net

and got this response:

550 5.7.1 External client with IP address 172.16.0.1 does not have permissions to submit to this server. Visit http://support.microsoft.com/kb/928123 for more information.

172.16.0.1 was IP address of external interface on ISA server…?!

Reason:

Sender reputation filter has characterized my own ISA server as a spammer, and added it to IP Block List for 24 hours..…;))

Solution:

I’ve removed 172.16.0.1 from IP Block List on Exchange server, add it to IP allow list and disabled Sender Reputation filter..…just in case…;)

Outlook 2007 and Default Gateway problem

2008-09-29T16:19:00Z

Since it is very popular to use Office 2007 nowadays, I've recently received a call from IT manager of a mid-size company (with whitch I have regular maintenance contract) to upgrade few machines from Office 2003 to Office 2007. They use Exchange 2003 Server with Outlook MAPI clients.

Great job for one of my junior squad members, I thought, and send one of them to do the job.

Not a long after, he called me saying that everything goes smooth but Outlook 2007 is reporting the error:
"The action cannot be completed. The connection to the Microsoft Exchange Server is unavailable. Your network adapter does not have a default gateway."

That was, actually, true. By design, the only way the user can access Internet was through proxy settings in their browsers.

Reason:

It is documented in http://support.microsoft.com/kb/913843 saying that "This problem may occur if the Outlook 2007 client computer does not have a default gateway configured." !??

Solution (part I):

I found that KB article and told him to navigate to "HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC" and add DWORD value DefConnectOpts vith value data of 0.
The only problem was that there was no "RPC" subkey above "HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook" key !?

Solution (part II):

If there is no subkey, maybe we should try to add it manually...and guess what...it worked...;)

Conclusion:

It is not a network if you don't have Default Gateway....;))..?

Certificate request problem - Error 0x00000046

2008-04-19T12:43:00Z

I've already resolved this one couple of times, but never document it before...;)

Yesterday, one of my clients called explaining me that secure section (https) of the internal web site is "not working" anymore. They use combination of IE 6, IE 7 and Firefox browsers, and said that in IE 6 and Firefox browsers popup window asks from them to continue, and IE 7 displays the page where users are asked to click on Continue link.

Reason:
It was obviously certificate problem, and after further investigation I found that certificate has expired.

Solution:
So, I've opened IIS Manager on the local Microsoft Windows 2003 Server and removed current certificate from secure portion of the web site. After that, I requested new certificate with the same parameters from online certification authority (Certificate Services running on the same server), completed the wizard successfully...and...nothing happened ?. Certificate was not generated...!?

Restart of Certificate Services didn't solve the problem.

Then, I've tried the alternate method through %servername%/certsrv, Advanced Certificate Request -> Web Server. After completing the form, and clicking on Submit button the following error appeared:

Advanced Certificate Request:

"An error occurred while creating the certificate request. Please verify that your CSP supports any settings you have made and that your input is valid.

Suggested cause:
You do not have write permission to save the file to the path Error: 0x00000046 - Permission Denied "

The problem was in permissions on local certificate store on CA server:
C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

Administrators and SYSTEM group needs Full Control permissions.

Advice:
Renew your certificates before expiration.....;)

OWA and PDF attachment problem

2008-04-15T21:37:00Z

A few days after successful implementation of Microsoft Small Business Server 2003 in a very small company, the Owner called me complaining that he cannot open PDF documents with a single click in OWA, while some of his employees can do that without any problems.

Because I don't believe end users (especially owners and managers), I logged with his credentials and tried to open the PDF attachment. This message appeared:
"To open this attachment, you must save it to your disk. Right-click the link, and then click Save. With a single-button mouse, hold the button down over the link, and then click Save."

Logging into OWA with other user credentials (one of the employees) from the same computer opened pdf with no problem into Internet Explorer. They were both members of Domain Users and local Administrators groups.

Huh ?

I've been already somewhat familiar with attachment blocking in OWA explained in:
http://support.microsoft.com/?kbid=555001

They say that "Level2 attachments have file extensions that can be accessed, but only if saved to the client's file system first."
But there is no PDF extension defined in Level2FileTypes registry key that could explain this behavior ?!

Investigating further I found that Exchange server 2003 SP1 introduces two new registry values
level1mimetypes and level2mimetypes but I couldn't find application/pdf or anything similar.

Reason:
No idea...?

Solution:
In the normal situation I would suggest the owner to follow that procedure because there are different security policies for the owner than from employees...or something similar...;)..but not with this one.

So at the end, I found the solution ...after removing "application/octetstream" from "HKLM\SYSTEM\Current Control Set\Services\MSExchangeWEB\level2mimetypes" PDF files opened with a single click in OWA, everything worked fine, everybody was pleased and......I was paid for my job...;))

Advice:
Install OWAADMIN.EXE tool from Microsoft site if you want to simplify/avoid registry editing.

KERBEROS error 4

2008-03-12T17:30:00Z

A few days ago one of my clients asked me to migrate ISA services from his old hardware to a brand new HP server.

Easy...;)

I joined the new server to the domain, duplicated network configurations (while disconnected, of course), copied hosts file, XML export-import ISA settings, disabled unnecessary services...etc.
At the end I removed the old box with the new one and connected it to the company network.
We tested inbound and outbound rules and everything worked fine.

Except...one of the domain controller (PDC emulator) started to report this event into its System log, every now and then:

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/isa.company.com. The target name used was HTTP/firewall.company.com. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (COMPANY.COM), and the client realm. Please contact your system administrator.

Reason:
The new server had a different name (ISA) than the old one (FIREWALL).

Solution:
I deleted A record "firewall" from the company DNS zone and the error disappeared.

Advice:
I prefer to use DNS CNAME "proxy" that points to the real name of company's ISA server. In the previous example nothing had to be changed on client machines, because they were already configured with "proxy.company.com" string in proxy settings on their internet browers (through group policy).