Request for next UpdatePack... Remote Desktop Fix

Questions about Update Pack making? Ask here.
Post Reply
User avatar
Siginet
Site Admin
Posts: 2894
Joined: Fri May 27, 2005 1:07 pm
Location: Planet Earth
Contact:

Request for next UpdatePack... Remote Desktop Fix

Post by Siginet » Fri Apr 03, 2009 6:24 pm

*Note* This is not an issue with any of the updatepacks... it is a flaw in SP3.

I recently experienced an issue with Remote Desktop on a freshly created disk of mine. Basically when I tried to use Remote Desktop through the internet I received an error that I had never seen before. Upon further research I found that the issue is caused when you slipstream SP3.

You can read more about it here:
http://mswhs.com/2008/05/20/remote-desk ... orkaround/

I think maybe this would be a good thing to add to any of the Post SP3 UpdatePacks.

Either that or it may be a good thing for us to add to the RVM Integrator?

What do you think?
Image
--Siginet--

Techware
Your Virtual Technician
Computer Management Software

yumeyao
Moderator
Posts: 1718
Joined: Sun Aug 27, 2006 9:24 pm
Location: Taiyuan, Shanxi, PR China

Post by yumeyao » Fri Apr 03, 2009 7:14 pm

We'd better not add it to the Integrator.

We fix wbemoc.inf, we fix svcpack.inf, we fix ..... we fix these stuffs since they BREAK WINDOWS INSTALLATION.

Let update pack do the job.
Image
My work list(Hosted by dumpydooby)

User avatar
galileo
Posts: 106
Joined: Sun Apr 22, 2007 8:11 pm
Location: Charlotte, NC USA

Post by galileo » Fri Apr 03, 2009 7:34 pm

@Sigi

After reading through several threads branching from your link, it seems as though this is an issue between XPSP3 and Windows Home Server...? Or does this issue manifest itself with any attempt to use RDP from an slipstreamed SP3 installation?

I have numerous XPSP3 (slipstreamed) installations (Ryan's, OnePiece's, and pure MS XPP+SP3) using IE7. Our users make considerable use of RDP over a VPN connection to our office through a Watchguard firewall and an SBS 2003 server and across our LAN. No problems/issues have shown up as yet with the IE7 ActiveX issues described in the various threads/blogs. But, none of our connections involve WHS at all.

Nonetheless, I would vote for providing a fix - but - the fix needs to be done in a way that would accommodate a future MS patch for this issue should one be issued. Generally, it would seem more rational for RVMI rather than the UPs to address issues that MS won't likely ever address since such issues would remain permanent for a given OS Service Pack level and thus, would require any/every UP to provide a fix.

@yume:

You make a good point regarding a potential philosophy for parsing the choice of where to provide the fix: Installation versus Operation. To wit, if an issue breaks the installation process then RVMI provides the fix versus if an issue causes the installed OS to function incorrectly "after a successful installatoin" then the UPs should provide the fix. There is some logic to establishing a guideline on "who" or "where" fixes are provided.

Although, in this particular instance, the files do in fact exist in the installation sources. They are simply not installed correctly very much like the wbemoc issue...perhaps this really does fall on the RVMI side of the parsing....???

galileo

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Fri Apr 03, 2009 7:48 pm

I'm very wary of having update packs "fix" things like this. I've never had a problem with RDP, and the link provided seems to suggest that this is only a problem for those who do this through IE (and is this IE7-only or does it affect IE6 as well?).

It's very easy to make a separate addon to fix things like this. Nor is it particularly burdensome to include an extra addon to the integration process. Unless there is a specific reason something needs to go into an update pack, the default stance should be "put it into an optional addon". (e.g., although a number of update pack makers have included the FontReg fix in their update packs, I actually keep it out of my personal-use update pack and include it separately in svcpack).
My addons: CmdOpen - HashCheck - Notepad2 - MS Runtimes - DirectX

Into the breach, meatbags!

User avatar
5eraph
Site Admin
Posts: 4619
Joined: Tue Jul 05, 2005 9:38 pm
Location: Riverview, MI USA

Post by 5eraph » Fri Apr 03, 2009 7:52 pm

Not everybody includes IE7. There appears to be no such ActiveX issue with IE6. Perhaps the fix should be limited to IE7 addons, if it's included at all.

User avatar
redxii
Posts: 395
Joined: Sun Dec 17, 2006 5:50 pm

Post by redxii » Fri Apr 03, 2009 7:55 pm

yumeyao wrote:We'd better not add it to the Integrator.

We fix wbemoc.inf, we fix svcpack.inf, we fix ..... we fix these stuffs since they BREAK WINDOWS INSTALLATION.

Let update pack do the job.
+1

If you're going to add that via the integrator, then that integrator better have an update pack inside it if you're gonna go that far.

And it's not a bug, it's really a feature. It's there to prevent ActiveX exploits, because as one of the posters on that page says, it is automatic in IE6, and you'll make everyone using IE vulnerable to exploits in Terminal Services.

User avatar
Siginet
Site Admin
Posts: 2894
Joined: Fri May 27, 2005 1:07 pm
Location: Planet Earth
Contact:

Post by Siginet » Sat Apr 04, 2009 11:13 pm

Well... from further research I was reading that someone said it only happens to SP3 slipstreamed disks. But also people stated if they remove ie7... select the option in ie6... then install ie7 they don't have an issue. Very odd. So it may be an ie7 issue instead of an SP3 issue.

It is an issue though. It is not a feature as redxii states. Because what happens is I don't have the option in ie7 to enable the terminal service activex addon on the computer.

RDP works perfectly fine. But not if you try to use it through IE7. The only way I have found to correct this is deleting that key from the registry.
Image
--Siginet--

Techware
Your Virtual Technician
Computer Management Software

User avatar
OnePiece Alb
Posts: 525
Joined: Sat Sep 01, 2007 7:01 pm
Location: Albania
Contact:

Post by OnePiece Alb » Sun Apr 05, 2009 9:04 am

Hello Siginet, I do not know when and valid, but tried to install this update solves nothing? http://support.microsoft.com/kb/963038/, said that because maybe used to update ryanvm pack and not been updated yet and not in this update, and perhaps this update solves the problem?

however, will probably take the number of error, and then look for it in http://kbupdate.info/windows-xp-r.php or see if some good kb of first talked about this thing, because I see in the eye that there Kb miles are about Remote Desktop, but almost all refer to SP2


Ciao.

User avatar
Siginet
Site Admin
Posts: 2894
Joined: Fri May 27, 2005 1:07 pm
Location: Planet Earth
Contact:

Post by Siginet » Sun Apr 05, 2009 11:43 am

No. I don't think that kb is a fix for the problem. But I'll do some testing.
Image
--Siginet--

Techware
Your Virtual Technician
Computer Management Software

User avatar
5eraph
Site Admin
Posts: 4619
Joined: Tue Jul 05, 2005 9:38 pm
Location: Riverview, MI USA

Post by 5eraph » Sat Apr 11, 2009 2:51 pm

More information on this issue and an official workaround can be found in KB951607. Whether the default status of the ActiveX control is a bug or a feature is dependent upon your point of view. It appears to be disabled by design.
Microsoft wrote:In Windows XP Service Pack 2 (SP2), you had to install the Msrdp.ocx file to enable the Terminal Services ActiveX control. Windows XP Service Pack 3 (SP3) already includes this ActiveX control and installs it by using the Mstscax.dll file. By default, this ActiveX control is disabled in Windows XP Service Pack 3 (SP3).

Post Reply