![]() The problem with that theory is that on Win2003, you get no resources back (as no one else is going to share that process) and you open yourself up to weird issues – when I tell Windows developers about issues caused services being modified by customers, their first response is “Why on earth would anyone change the service? We don’t test for that at all!” You might think it was OK to change this on Win2003 to stop the error and maybe even get back some resources. Svchost.exe exists mainly to lower computer resource usage: the more DLLs that can run in fewer shared processes, the less memory/CPU the OS has to allocate for services. Later versions of Task Manager make this easier too, if you’re allergic to command-line: %systemroot%\system32\svchost.exe –k RPCSS ![]() You can see who would launch in that same process by looking for this value in the service registry keys: In Win2008 R2, the new RPCEptMapper service was added to that shared svchost. Your assumption around shared versus isolated is totally correct:īetween Win2003 and Win2008, the behavior changed for the RPC service, but there was nothing yet to “share” in that ![]() Win2008 DCDIAG doesn’t know that Win2003 was designed this way so he can’t give you a reasonable answer – he just wants it to be default in 2008 terms. Do not change it based on what DCDIAG says unless you are running the version of DCDIAG that goes with that OS (this is where much of the Internet got confused on causality versus correlation). ![]() It’s expected and normal for this service’s behavior type to be 0x10 on Win2003 and 0x20 on Win2008 and later. Do you know why this is different and what’s going on? It looks like the difference is being a service in a shared versus isolated process. That say I should change the value using theĬommand. WIN32_OWN_PROCESS, expected value WIN32_SHARE_PROCESS Invalid service type: RpcSs on DC01, current value It tells me the Windows Server 2003 DCs are failing a service test around RPCSS: I have a mixed environment of Win2003 and Win2008 DCs. ![]() Profile conversion from workgroup to domain joined computers MIGAPP.XML compatibility between USMT 3.01 and 4.0 Today we talk DCDIAG, DFSN, DFSR, group policy, user profiles, migrations, USMT, and the fuuuuuuturrrrrrrrre. First published on TechNet on Feb 11, 2011 ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |