SCCM Client Push Fails
scott.w...@evolving.com
I have a SMS environment side by side with a new SCCM environment and I can
not get the client push to work on most of my workstations after migrating
to SCCM. Oddly enough its random. Discover works fine assigns a site code
Client push account is smsremote and is a domain admin. I log in with the
smsremote account and have no problems accessing the admin$. I know
00000005 is typically a access is denied but that just cant be the case.
(of course unless i missed something) Domain admin all around.
When trying to remote WMI to the client from the SCCM server it fails
(Although I can connect to that client's wmi remotely from another client,
just not from any server including the SCCM server). "Failed to connect to
\\client because "Win32 The RPC Server is unavailable" and posts a Event iD
10009 in the event viewer. "DCOM was unable to communicate with the
computer clientname using any of the configured protocols." Verified DCOM
permissions has local administrators (which includes domain admins) with
remote access even gave "everyone" rights to no avail. .
Verified local WMI Security includes Local Administrators.
Firewall on Server and Client are turnned off for the time being.
Tried portqry -n clientname -e 135 and receive a "RPC query failed (6bf)"
error
SCCM server - Windows 2008/Sql 2008 backend
Client - XP Pro SP3
Nothing gets posted to C:\WINDOWS\system32\ccmsetup on the client.
Exert from ccm.log:
======>Begin Processing request: "clientcomputername_domain_COM.domain",
machine name: "clientcomputername" SMS_CLIENT_CONFIG_MANAGER 11/24/2009
5:24:15 AM 5684 (0x1634)
---> Trying the account stored in the CCR (index = 0x0)
SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:15 AM 5684 (0x1634)
---> Attempting to connect to administrative share
'\\clientcomputername.domain.com\admin$' using account 'domain\smsremote'
SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:15 AM 5684 (0x1634)
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account
domain\smsremote (00000005) SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:16 AM
5684 (0x1634)
---> Connected to administrative share on machine
clientcomputername.domain.com using account 'domain\smsremote'
SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:16 AM 5684 (0x1634)
---> Attempting to make IPC connection to share
<\\clientcomputername.domain.com\IPC$> SMS_CLIENT_CONFIG_MANAGER 11/24/2009
5:24:16 AM 5684 (0x1634)
---> Searching for SMSClientInstall.* under
'\\clientcomputername.domain.com\admin$\' SMS_CLIENT_CONFIG_MANAGER
11/24/2009 5:24:16 AM 5684 (0x1634)
CWmi::Connect(): ConnectServer(Namespace) failed. - 0x800706ba
SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:32 AM 6124 (0x17EC)
---> Unable to connect to WMI on remote machine "clientcomputer2", error =
0x800706ba. SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:32 AM 6124 (0x17EC)
---> Deleting SMS Client Install Lock File
'\\clientcomputer2.domain.com\admin$\SMSClientInstall.00A'
SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:32 AM 6124 (0x17EC)
Stored request "clientcomputer2_ESI1_EVOLVING_COM", machine name
"clientcomputer2", in queue "Retry". SMS_CLIENT_CONFIG_MANAGER 11/24/2009
5:24:32 AM 6124 (0x17EC)
<======End request: "clientcomputer2_ESI1_EVOLVING_COM", machine name:
"clientcomputer2". SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:32 AM 6124
(0x17EC)
CWmi::Connect(): ConnectServer(Namespace) failed. - 0x800706ba
SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:37 AM 5684 (0x1634)
---> Unable to connect to WMI on remote machine "clientcomputername", error
= 0x800706ba. SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:37 AM 5684 (0x1634)
---> Deleting SMS Client Install Lock File
'\\clientcomputername.domain.com\admin$\SMSClientInstall.00A'
SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:37 AM 5684 (0x1634)
Stored request "clientcomputername_domain_COM.domain", machine name
"clientcomputername", in queue "Retry". SMS_CLIENT_CONFIG_MANAGER 11/24/2009
5:24:37 AM 5684 (0x1634)
<======End request: "clientcomputername_domain_COM.domain", machine name:
"clientcomputername". SMS_CLIENT_CONFIG_MANAGER 11/24/2009 5:24:37 AM 5684
(0x1634)
thanks for your help!
Scott
Garth
It sounds like a DNS/WINS problem:
. Pick a WS that is having problem.
. Ping he WS by name, note the IP address
. Take that IP address and ping -a <IP>, is the name the same as
above?
. Do an nbtstat -a <IP>, do you see the computer name in the
list?
. Using wbemtest connect to \\<IP>\root\cimv2
<file:///\\%3cIP%3e\root\cimv2> Then review the results for
win32_ComputerSystem, is the name what you expect?
If any of these three tests don't show you the PC name that you are
expecting then your issue is with DNS/WINS.
"scott.w...@evolving.com" <scott.w...@evolving.com> wrote in
message news:#RVZD#VbKHA...@TK2MSFTNGP02.phx.gbl:
> Dear group,
>
>
> error
>
>
>
>
>
>
>
> Exert from ccm.log:
>
> 5684 (0x1634)
> <\\clientcomputername.domain.com\IPC$> SMS_CLIENT_CONFIG_MANAGER 11/24/2009
> '\\clientcomputername.domain.com\admin$\' SMS_CLIENT_CONFIG_MANAGER
> '\\clientcomputer2.domain.com\admin$\SMSClientInstall.00A'
> (0x17EC)
> '\\clientcomputername.domain.com\admin$\SMSClientInstall.00A'
> (0x1634)
>
>
> thanks for your help!
> Scott
--
Garth Jones
Chief Architect
Enhancing Your Business
Scott Wom
tests/nbtstat -a test comes back with correct IP and sucessfull response.
However running wbemtest connect to \\<IP>\root\cimv2 I get
Number: 0x800706ba
Facility: Win32
Description: The RPC server is unavailable.
I verified RPC service on WS is running as well as DCOM.
RPC
Scott
"Garth" wrote:
> It sounds like a DNS/WINS problem:
>
> .. Pick a WS that is having problem.
>
> .. Ping he WS by name, note the IP address
>
> .. Take that IP address and ping -a <IP>, is the name the same as
> above?
>
> .. Do an nbtstat -a <IP>, do you see the computer name in the
> list?
>
> .. Using wbemtest connect to \\<IP>\root\cimv2
> .
>
Scott Wom
\\WSName\root\cimv2, just not from any servers (including the new SCCM
server). Our servers are on a differnet subnet than the clients, maybe thats
the isssue?? No FW between subnets, they are all under the same x.x.x.x/22
class B. SMS had no issues with this...
Garth
It not the correct IP address you are looking for, it is the correct
NetBIOS Name.
/22 subnet is huge! Why using such a large subnet? Are the clients
really using /22 subnet mask or are they using a /24 or smaller subnet
mask? If the subnet mask is not correct, you will have problems
installing the client.
"Scott Wom" <Scot...@discussions.microsoft.com> wrote in message
news:56CDDF3E-1732-42DA...@microsoft.com:
Scott Wom
build the network. I spoke with our Network Engineer and he says he plans on
resolving that some day. Never the less the client and server communicate
fine. (excluding wmi of course).
When I use WBEMTEST from Server to \\ <IP> \root\cimv2 I get the error :
---------------------------------------------------
Number: 0x800706ba
Facility: Win32
Description: The RPC server is unavailable.
RPC service is running on client w/o issue. DCOM permissions ok. F/W off
for the time being. I can even connect to client's wmi from another client
w/o issues. Its somehow just has a problem connecting from SCCM server to
the clients.
--------------------------------------------------
Results of previously requested tests: I replaced actual host name and IPs.
C:\Windows\system32>ping clienthostname
Pinging clienthostname.domain.com [x.x.x.x] with 32 bytes of data:
Reply from x.x.x.x: bytes=32 time=8ms TTL=128
Reply from x.x.x.x: bytes=32 time<1ms TTL=128
Reply from x.x.x.x: bytes=32 time<1ms TTL=128
Reply from x.x.x.x: bytes=32 time<1ms TTL=128
Ping statistics for x.x.x.x:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 8ms, Average = 2ms
C:\Windows\system32>ping -a x.x.x.x
Pinging clienthostname.domain.com [x.x.x.x] with 32 bytes of data:
Reply from x.x.x.x: bytes=32 time<1ms TTL=128
Reply from x.x.x.x: bytes=32 time<1ms TTL=128
Reply from x.x.x.x: bytes=32 time<1ms TTL=128
Reply from x.x.x.x: bytes=32 time=2ms TTL=128
Ping statistics for x.x.x.x:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 0ms
C:\Windows\system32>nbtstat -a x.x.x.x
Local Area Connection:
Node IpAddress: [10.10.12.102] Scope Id: []
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
clienthostname <00> UNIQUE Registered
clienthostname <20> UNIQUE Registered
domain <00> GROUP Registered
domain <1E> GROUP Registered
MAC Address = 00-xx-70-xx-04-xx
"Garth" wrote:
> .
>
Garth
/22 != 255.255.255.252 aka /30
To install the ConfigMgr client the subnet must match the ConfigMgr
boundaries to properly install. In order to fix this correctly you need
to do one of the following things:
. Fix the subnetting
. Enter each subnet into AD and use AD Sites for ConfigMgr
boundaries (and update them every time they get updated.)
. Enter each subnet into ConfigMgr boundaries (and update them
every time they get updated.)
I still want to say it is a DNS/Network issue but you are saying that
Ping and NBTStat is OK, both firewalls are turned off, and security is
fine then I have no idea as to why it would be failing.
"Scott Wom" <Scot...@discussions.microsoft.com> wrote in message
news:F9F24F58-2D45-4182...@microsoft.com:
Scott Wom
Some more info:
I have a forest with 4 domains. SCCM is in root of forrest. I have three
child domains in three other countries with their own sites in AD. Clients
get assigned a site code without issues. (boundries are working).
In CCM logs i get multiple errors like this for multiple boxes.
---> Unable to connect to WMI on remote machine "clientname", error =
0x800706ba.
and
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account
domain\smsremote (00000005)
Im aware 5 usually means permissions but domain\smsremote is a domain admin
in all domains with synced passwords and local administrators contain domain
admins. What other security should I check? Any security on SCCM server
(Windows 2008) for remote WMI that Im missing?
and
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account
domain\smsremote (00000035)
smsremote is a domain admin.
and
CWmi::Connect(): ConnectServer(Namespace) failed. - 0x800706ba
Thanks again for your help! I really do appreciate it.
"Garth" wrote:
> You have a couple of issues that I see.
>
>
>
> /22 != 255.255.255.252 aka /30
>
> To install the ConfigMgr client the subnet must match the ConfigMgr
> boundaries to properly install. In order to fix this correctly you need
> to do one of the following things:
>
> .. Fix the subnetting
>
> .. Enter each subnet into AD and use AD Sites for ConfigMgr
> boundaries (and update them every time they get updated.)
>
> .. Enter each subnet into ConfigMgr boundaries (and update them
Sherry Kissinger [MVP]
http://blogs.technet.com/askperf/pages/wmi-can-t-connect-to-remote-wmi.aspx
Additionally, I have (I'm sorry to say) a vague memory about an October
hotfix that randomly affected some remote capabilities of XP workstations. I
can't recall the exact hotfix it was tho. But that's a complete stab in the
dark anyway.
Garth
mask? This is a monster broadcast domain!
Although this should have nothing to do with your WMI connection issues.
Sherry's note about troubleshooting WMI is a good place to start.
"Scott Wom" <Scot...@discussions.microsoft.com> wrote in message
news:75BB4FA3-5AAD-4BB4...@microsoft.com:
Scott Wom
"to do list" to change that.
More info:
I would think there is something wrong the the problem client's WMI, BUT i
have no problems remote connecting to that client from another xp client just
from the SCCM server (which is kinda important ;) ). Never the less, i went
through the documentation and security on WMI was fine, DCOM Security was
fine. I did get a couple errors (pasted below) in wmidiag on that machine
but am unsure how to resolve them. I tried registering the dll's it refered
to but it still comes back with same message after I ran wmidiag a second
time.
As for the "Overall WMI security" error. I have no idea how to fix that.
That being said, Im still not thinking its a client wmi issue but more a
sccm server issue, otherwise why can I wbemtest from another client to the
problem client w/o issues? What do I check on the server?
Lastly, when connecting to the problem client the server posts a event in
the event log.
DCOM was unable to communicate with the computer XPCLIENT using any of the
configured protocols.
Netbios is enabled on NIC. checked that as well.... Thanks for your help.
53314 15:43:42 (2) !! WARNING: WMI DCOM components registration is missing
for the following EXE/DLLs: .................................... 6 WARNING(S)!
53315 15:43:42 (0) ** - C:\WINDOWS\SYSTEM32\WBEM\FASTPROX.DLL
(\CLSID\{7A0227F6-7108-11D1-AD90-00C04FD8FDFF}\InProcServer32)
53316 15:43:42 (0) ** - C:\WINDOWS\SYSTEM32\WBEM\FASTPROX.DLL
(\CLSID\{D71EE747-F455-4804-9DF6-2ED81025F2C1}\InProcServer32)
53317 15:43:42 (0) ** - C:\WINDOWS\SYSTEM32\WBEM\FASTPROX.DLL
(\CLSID\{ED51D12E-511F-4999-8DCD-C2BAC91BE86E}\InProcServer32)
53318 15:43:42 (0) ** - C:\WINDOWS\SYSTEM32\WBEM\WBEMPROX.DLL
(\CLSID\{4C6055D8-84B9-4111-A7D3-6623894EEDB3}\InProcServer32)
53319 15:43:42 (0) ** - C:\WINDOWS\SYSTEM32\WBEM\WBEMPROX.DLL
(\CLSID\{A1044801-8F7E-11D1-9E7C-00C04FC324A8}\InProcServer32)
53320 15:43:42 (0) ** - C:\WINDOWS\SYSTEM32\WBEM\WBEMPROX.DLL
(\CLSID\{F7CE2E13-8C90-11D1-9E7B-00C04FC324A8}\InProcServer32)
53321 15:43:42 (0) ** => WMI System components are not properly registered
as COM objects, which could make WMI to
53322 15:43:42 (0) ** fail depending on the operation requested.
53323 15:43:42 (0) ** => For a .DLL, you can correct the DCOM configuration
by executing the 'REGSVR32.EXE <Filename.DLL>' command.
53908 15:43:42 (1) !! ERROR: Overall WMI security status:
................................................................................. ERROR!
53909 15:43:42 (0) ** - Started at 'Root'
--------------------------------------------------------------------------------------------------------------
53910 15:43:42 (0) ** INFO: WMI permanent SUBSCRIPTION(S):
................................................................................ 6.
53911 15:43:42 (0) ** - ROOT/CCM/POLICY,
CCM_PolicyReplicationConsumer.Id="{9099D177-1AD6-46e6-BBC0-70F460786953}".
53912 15:43:42 (0) ** 'SELECT * FROM __ClassOperationEvent WHERE
TargetClass ISA "CCM_Policy_Config"'
53913 15:43:42 (0) ** - ROOT/CCM/POLICY,
CCM_PolicyReplicationConsumer.Id="{9099D177-1AD6-46e6-BBC0-70F460786953}".
53914 15:43:42 (0) ** 'SELECT * FROM __NamespaceCreationEvent'
53915 15:43:42 (0) ** - ROOT/CCM/POLICY,
CCM_PolicyReplicationConsumer.Id="{9099D177-1AD6-46e6-BBC0-70F460786953}".
53916 15:43:42 (0) ** 'SELECT * FROM __ClassOperationEvent WHERE
TargetClass ISA "CCM_Policy"'
53917 15:43:42 (0) ** - ROOT/CCM/POLICY,
CCM_PolicyReplicationConsumer.Id="{9099D177-1AD6-46e6-BBC0-70F460786953}".
53918 15:43:42 (0) ** 'SELECT * FROM __ClassOperationEvent WHERE
TargetClass ISA "CCM_Policy_EmbeddedObject"'
53919 15:43:42 (0) ** - ROOT/SUBSCRIPTION,
MSFT_UCScenarioControl.Name="Microsoft WMI Updating Consumer Scenario
Control".
53920 15:43:42 (0) ** 'SELECT * FROM __InstanceOperationEvent WHERE
TargetInstance ISA 'MSFT_UCScenario''
53921 15:43:42 (0) ** - ROOT/SUBSCRIPTION, NTEventLogEventConsumer.Name="SCM
Event Log Consumer".
53922 15:43:42 (0) ** 'select * from MSFT_SCMEventLogEvent'
53923 15:43:42 (0) **
Garth
It look like it is time to re-build the WMI on this PC to see if that
fixes your issues. However it has been recommend that before rebuilding
WMI that you connect MS support so that they can work through all the
WMI issue and only re-built it as a last resort.
"Scott Wom" <Scot...@discussions.microsoft.com> wrote in message
news:7A76E19B-2FAB-47E2...@microsoft.com:
Scott Wom
We found a bug in our checkpoint vpn client that can cause issues with RPC
traffic, even when the services for Checkpoint VPN client are stopped. I
used http://support.microsoft.com/kb/899148 and added the reg hack to
Windows 2008(even thought the technote doesn’t say how to update 2008 server)
The windows 2008 Server should use RPC-based operations to function as pre
"multiple transfer syntax negotiation."
Just thought Id post our findings.. uggggg that took forever.