Re: MSKB 891957, VSS Update for Windows Server 2003

Well, it turns out the RDP connection dropping issue won't go away,
Coraleigh. Last night I stayed connected to the 2003 server for over
half an hour. I connected strictly for test purposes and left the
connection sit idle. No dropout. This afternoon, I connected to do a
file restore operation for a user and the connection dropped within
less than two minutes! It would seem that either Internet traffic
levels at either my end or the office end or local network traffic
level to the server in the office may have an affect on the issue.
I'll review the article with the registry hacks to see if one or more
of the entries can be adjusted to compensate for higher traffic
(longer latency) levels.

Ah, I just remembered I also re-installed RDP Client V6 last night as
well. I will revert back to V5 to see if that helps.


On Sun, 09 Sep 2007 20:43:24 -0700, Bob Felton
<bob123.removethis@xxxxxxxxxxxxx> wrote:

Just wanted to let you know, Coraleigh, that the same registry entries
when added to a Windows XP Pro based machine acting as an email and
FTP server also resolved the flaky RDP connections to it. So, a
hearty "Thanks!" for pointing me to them.
--
Bob


On Thu, 06 Sep 2007 22:32:07 -0700, Bob Felton
<bob123.removethis@xxxxxxxxxxxxx> wrote:

Hi, Coraleigh! I created the registry entries shown in the article
you referenced today and have done some testing from home tonight. So
far, RDP connections have not dropped out. The longest session I
tried was about 6 minutes. I haven't been able to have one that long
since moving to the "2003" server. So, "Thanks!" for that tip.

Further, I left the server with user Backup logged in when I left the
site today. I will check tomorrow if the VSS error appeared in Event
Viewer.
--
Bob


On Sat, 1 Sep 2007 18:58:06 -0700, "Coraleigh Miller"
<CoraleighMiller@xxxxxxxxx> wrote:

Oh that would drive me nuts! I use RDP for pretty much all of my server
work.

These are some RDP config suggestions which may help...
http://terminal.servebeer.com/php/flaky_connections.php
If these dont resolve your issue...
Does this happen from other pcs as well as yours? If yes..
Are you able to ping the server by ip or name during a dropout? Do you have
more than one network card in the server, if you do and dont use it you
should disable it and remove any bindings. You could also try upgrading the
nic driver. You could try using a different port on your switch. If you
have a few network devices between your PC and the server (or if this is
connecting from external remote) then try using the pathping or tracert
command to see where the connection is dropping. If this is happening when
rdp to more than just this server I would look closer at your network
devices.

Coraleigh Miller




"Bob Felton" <bob123.removethis@xxxxxxxxxxxxx> wrote in message
news:iv1kd3licru8i4t2kvopd0vbmdu8edq4f2@xxxxxxxxxx
Scratch that RDP fix! I just had an RDP dropout after less than 3
minutes. RDP into the old Windows 2000 Server server worked great.
RCP into the Windows Server 2003 server it really hit an miss.
Sometimes it stays connected for longer than 3 minutes and sometimes
less. It is a real pain to work on the serve remotely with the
dropouts as it takes about 15 minutes after a dropout for some timeout
to reallow RDP login. Ugghh!


On Sat, 01 Sep 2007 17:36:21 -0700, Bob Felton
<bob123.removethis@xxxxxxxxxxxxx> wrote:

Thank you very much, Coraleigh, for your extensive testing and
confirmation of the exact problem I'm having. I think the fix I'm
going to use is just to leave user Backup logged in at the console,
which is what I used to do. However, I started experiencing RDP
connection dropouts when logging in as user Administrator remotely.
In an attempt to resolve that problem, I started to leave the server
in a no active user logged in mode. I have since resolved the RDP
issue by reverting my RDP client back to version 5 (there seems to be
a problem with version 6).

I will use RDP to create a user Backup login and see if the next
scheduled backup (Monday night) generates the error.

Thanks, again, Coraleigh for all your effort on this matter.
--
Bob


On Fri, 31 Aug 2007 20:49:30 -0700, "Coraleigh Miller"
<CoraleighMiller@xxxxxxxxx> wrote:

Hi Bob,

So I spent some time the last couple of days trying to break my test
server
to get the same error and issue descriptions you told me, lol, great fun.
And I succeeded. I tried many many things testing each along the way, and
finally a System32 permissions change with some subfolder replication
(dont
try this at home kids) finally did the trick. Once I created the issue,
I
tried to fix it backing out each step, however surprise surprise i was
unable to get all my permissions back correctly, though i did alot of
painful file version permission comparison against another test server i
have which i knew to do error free backups. The issue, at least with my
12289 error, seems to be with the Backup Operators Group permissions.

I can run an error free backup with a Backup Operators group account as
long
as im logged in as that user, both scheduled and immediate. The error
happens when i am not logged in as the user of the Backup Operators group
while the scheduled backup runs. The only event log error is the 12289
and
it appears in the log right after an 8018 info NTBackup "begin operation"
event, and right before an 8000 info NTBackup "Begin Backup of C:" event.

Unfortunately I wasnt able to fix this issue, but I did find 2 successful
workarounds for this..either make your backup account a member of the
Domain
Admins group or, and i like this idea better cause of security, log into
your server via remote desktop as your backup account and then disconnect
leaving your session running.

Things I tried as fixes that didnt work (not neccessarily in order)...
(My test systems: Windows 2003 SP1 w/all fsmo roles, isolated domains,
both
are fresh installs)
-Checked and matched all file versions and security, that i could think
were
affected, against known good server
-installed Sp2 plus all added hotfixes (didnt apply any requiring an MS
call, but might in future)
-created a new backup account and linked with Backup Operators
-elevated Backup Operators file level permissions on all files i thought
would be affected
-added backup user to each of the associated backup DCOMs (dcomcnfg.msc)
-set backup services (VSS and Removable Storage) as well as scheduled
tasks
to run using the administrator account
-Ran process manager in administrator TS session while the backup was set
to
run using backup user credentials, didnt find anything that looked wrong
in
the results though.
-Checked within the security policy (secpol.msc) that the Backup
Operators
group was set as being allowed to run backups
-totally cleaned out any old backup jobs and associated files


Even though i am getting this 12289 error, my backups still work and test
well, make sure yours contain viable data as well and then, if they are
good
backups, either use a workaround or ignore the error and wait for
Microsoft
to release another fix which might address the error.

Or.. maybe someone else here has another idea? :-)

Coraleigh Miller

"System Administrator" <sysadmin@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:46d74954.1643826656@xxxxxxxxxxxxxxxxxxxxxxx
I just tried a manual test backup while logged in as user Backup.
Again, no VSS errors were logged.
--
Bob


On Thu, 30 Aug 2007 22:45:30 GMT, sysadmin@xxxxxxxxxxxxxxxxxxxxxxxx
(System Administrator) wrote:

Further to my previous, Coraleigh. FWIW, the scheduled backups are
fired off using user "Backup" credentials. This user is a member of
the Backup Operators group.
--
Bob


On Thu, 30 Aug 2007 21:55:34 GMT, sysadmin@xxxxxxxxxxxxxxxxxxxxxxxx
(System Administrator) wrote:

OK, Coraleigh, I have some answers for you:

1. The full message for Event ID 12289 being logged is:

Volume Shadow Copy Service error. Unexpected error OpenService
(shSCManager, 'VSS',SERVICE_QUERY_STATUS). hr=0x80070005.

2. There are several other events being logged related to the
scheduled backup. All of which are informational (backup progress
related) only. The 12289 event is the only error event being logged
and it comes immediately after an informational event indicating the
scheduled backup operation had started. There are two informational
events after the 12289 event indicating a shadow copy freeze start and
stop. The next five informational events show NTBackup start,
completion, operation successful, verify start and completion.

3. No errors are logged when backing up a single file using the
NTBackup user interface. The VSS events are all coming from the daily
(M-F) scheduled NTBackup backups.

4. I do not recall and can't determine if the issue started after a
particular Windows Update procedure as I empty the event log file
weekly. I do not recall them appearing immediately after system
installation, which included SP2. However, the backup tests conducted
after system installation were all made from the user interface. I do
not recall if any VSS events were logged once I began using scheduled
backups.

5. No errors were indicated when I ran "vssadmin list writers".

6. When I ran "sfc /scannow", several prompts to insert the install
CD were issued. For each prompt, I chose "Cancel" and after ten or so
prompts, I cancelled the entire procedure. Since the install CD was
being prompted for, wouldn't allowing each prompt to complete
overwrite a file that may have been updated by either the SP2 update
or a Windows Update?

7. I did not attempt to use Process Monitor as NTBackup via the user
interface did not generate a VSS event in Event Viewer.

FWIW, I have not explicitly configured anything related to VSS.
NTBackup seems to use it as a matter of course, using whatever default
configuration exists for it.

Hope this information helps in determining the problem. Thanks,
Coraleigh.
--
Bob


On Mon, 27 Aug 2007 23:07:55 -0700, "Coraleigh Miller"
<CoraleighMiller@xxxxxxxxx> wrote:

Hi Bob,

Ok I have a bunch of questions and troubleshooting tools for you...
:-)

What is your full event id 12289 error message?
Do you have any other related event ids in your log?
Do you get the error even with backing up a simple single file on the
originating server? -is it a specific type of backup which produces
this
error?
When this problem started occuring were there any new updates or
software
installed, or new configuration?

Do any errors show up if you run a vssadmin /listwriters?
http://technet2.microsoft.com/windowsserver/en/library/89d2e411-6977-4808-9ad5-476c9eaecaa51033.mspx?mfr=true

You could run a sfc /scannow http://support.microsoft.com/kb/310747
which
examines all of your protected system files and verifies their
versions
against what you are supposed to have. It may be that there is an
incorrect
version system file outside of the vss ones we looked at.

You could also try using Microsoft's Process Monitor
http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx
This will help to show what files are being launched when you start a
backup. And it might give us abit more info.
When you go to use it make sure that all other programs are closed,
as
it
will be easier to see our data this way, and then press the clear
button
at
the top and then launch your mmc, then press the capture button again
which
will halt the process explorer allowing you to view the info. For
viewing
the file names it might be easier to have only the "Show file system
activity" button at the top pressed.

Coraleigh Miller


"Bob Felton" <bob123.removethis@xxxxxxxxxxxxx> wrote in message
news:1d87d35vp18b0li3kir9bf0gg4jr9jbsdk@xxxxxxxxxx
Thanks for that research, Coraleigh. I looked at KB913648. It
indicates all the associated files (x86) are at version
5.2.3790.2669
with a date stamp of 28 Mar 06. The files on my server are at
version
5.2.3790.3959 with a date stamp of 4 Apr 06, except for a few that
have 17 Apr 07, which I believe is the date I built up the server.
So, it would appear that I have newer files than indicated in
KB913648
yet I am still receiving the VSS event. Anything else I can look
at
or do in an attempt to resolve? Thanks.


On Wed, 22 Aug 2007 14:44:51 -0700, "Coraleigh Miller"
<CoraleighMiller@xxxxxxxxx> wrote:

Hi Bob,

This update (also included in SP2) is actually newer and replaced
the
891957
doc so you might want to check against the file dates from here
instead..
http://support.microsoft.com/kb/913648/

Coraleigh


"Coraleigh Miller" <CoraleighMiller@xxxxxxxxx> wrote in message
news:uNYQWJH5HHA.3684@xxxxxxxxxxxxxxxxxxxxxxx
Hmm..well i suppose you could check the updated files listed in
the
891957
doc to see if the ones on your server are the same ver and date
as
the
891957 files, i would think that if a few of them were older then
the
891957 for some reason didnt apply correctly, or the files got
overwritten
by some other app (not sure how possible this is). Were there any
errors
in your SP2 install log?

Coraleigh

"Bob Felton" <bob123.removethis@xxxxxxxxxxxxx> wrote in message
news:ppcnc3dr096hgtu1mp9leui37huo65jh4i@xxxxxxxxxx
No, Coraleigh, not yet. The 4/14/2006 response on EventID.net
was
for
the same exact event I'm receiving and it is the one that
mentioned
KB
891957.


On Tue, 21 Aug 2007 20:09:06 -0700, "Coraleigh Miller"
<CoraleighMiller@xxxxxxxxx> wrote:

Hi Bob,

The 891957 is listed as being included in 2003 SP2.
http://support.microsoft.com/kb/914962
Did you try the other suggestions at eventid.net?


Coraleigh Miller

"Bob Felton" <bob123.removethis@xxxxxxxxxxxxx> wrote in message
news:k2smc3h54265iku4bcgdr3lfhfj1r409nj@xxxxxxxxxx
Does anyone know if the update contained in MSKB 891957 was
incorporated into SP2 for Windows Server 2003 R2? I am
receiving
Event ID 12289 from VSS just as a scheduled NTBackup kicks
off.
MSKB
891957 was pointed to from EventID.net as a solution for Event
ID
12289. However, I already have SP2 installed and am still
logging
the
events. Thanks.
--
Bob Felton


--
Bob Felton




--
Bob Felton



--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA


--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA


--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA



--
Bob Felton


--
Bob Felton
.