smlets error: "The requested name is valid, but no data of the requested type was found"

Mar 1, 2013 at 1:16 PM
Edited Mar 1, 2013 at 10:36 PM
Hi,

We are facing this error in our preproduction environnement (SCSM 2010 SP1, smlets Béta4).
Everything is working fine on the production environnement, which is the same version for all components.

Every cmdlet that need to access SCSM server return this error (example with get-SCSMClass) :
PS C:\> Get-SCSMClass
Get-SCSMClass : The requested name is valid, but no data of the requested type was found
At line:1 char:14
+ Get-SCSMClass <<<<
    + CategoryInfo          : InvalidOperation: (localhost:String) [Get-SCSMClass], SocketException
    + FullyQualifiedErrorId : GenericMessage,SMLets.GetSMClassCommand
Does anybody know where it come from ?

Regards,
C.
Developer
Mar 1, 2013 at 7:36 PM
Is it possible that you've created some new classes? Or are trying to use the wrong version of the cmdlets against the service?
it's hard to tell from this message, but you should be able to get more detail via $error. Immediately following this error, try looking at the contents of $error

$error[0]|fl -force
$error[0].Exception|fl -force
$error[0].Exception.InnerException|fl -force
Mar 1, 2013 at 10:35 PM
Thanks for your hint.

To answer your questions, we created some new custom classes, but not recently.
The smlets has worked fine I think for a while on this environnement, or at least, they work on the production environnement which is all the same versions as this one. I can't say exactly when it start malfunctionning...

To be sure that it was not a version problem, I juste re-install the smlets this morning before posting this problem (with need to build as our SCSM has been patched). But I have the same error after that.

The $error[0].Exception show an error number (11004) that gave more information about the problem.
PS C:\ > $error[0].Exception|fl -force
ErrorCode       : 11004
Message         : The requested name is valid, but no data of the requested type was found
SocketErrorCode : NoData
NativeErrorCode : 11004
Data            : {}
InnerException  :
TargetSite    : System.Net.IPHostEntry GetAddrInfo(System.String)
StackTrace   :  at System.Net.Dns.GetAddrInfo(String name)
                     at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
                     at System.Net.Dns.GetHostAddresses(String hostNameOrAddress)
                     at Microsoft.EnterpriseManagement.Common.Internal.ServerDefinition..ctor(EnterpriseManagementConnectionSettings connectionSettings, Type groupType, Type coreType)
                     at Microsoft.EnterpriseManagement.Common.Internal.SdkDataLayerProxyCore.RetrieveEnterpriseManagementGroupInternal[T,P](EnterpriseManagementConnectionSettings connectionSettings, ClientDataAccessCorecallbackDispatcherService)
                     at Microsoft.EnterpriseManagement.Common.Internal.SdkDataLayerProxyCore.Connect[T,P](EnterpriseManagementConnectionSettings connectionSettings, ClientDataAccessCore callbackDispatcherService)
                     at Microsoft.EnterpriseManagement.EnterpriseManagementGroup.InternalInitialize(EnterpriseManagementConnectionSettings connectionSettings, EnterpriseManagementGroupInternal internalsProxy)
                     at SMLets.ConnectionHelper.GetMG(String computerName, PSCredential credential)
                     at SMLets.SMCmdletBase.BeginProcessing()
HelpLink        :
Source          : System
I found this interesting link about Windows Sockets Error Codes :
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx

Including my error :
WSANO_DATA (11004)
Valid name, no data record of requested type.
The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record—indicating the host itself exists, but is not directly reachable.

--> Nevertheless, I still don't understand the problem I have as DNS server seems to be configured the same as previously, SCSM server is well registered (A record), and is indeed reachable.
Do you know which port does smlets try to use to connect SCSM service ?

I tried too to launch the Get-SCSMClass with -ComputerName argument :
PS C:\> Get-SCSMClass -ComputerName <hostname>
PS C:\> Get-SCSMClass -ComputerName <hostname.fqdn>
PS C:\> Get-SCSMClass -ComputerName localhost
They all have the same result (error 11004).

Any Idéa ?

Thanks
Developer
Mar 1, 2013 at 10:50 PM
I'm out of ideas, sorry.

I left the Service Manager team about 14 months ago, so I'm also out of touch with changes. I would start looking at whether you've patched the system (perhaps there's a new version or SP for SM). You might try creating an EnterpriseManagementGroup object and seeing if you can directly access the service endpoint. This is all from memory, so you might have to try some other things:

$EMG = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup <computername>
$EMG.Classes.GetClasses()

or something like that

good luck!
Mar 4, 2013 at 10:29 AM
Hi,

When I create an EntrepriseManagementGroup, it works :

$EMG = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup <computername>
$EMG.EntityTypes.GetClasses()
--> get the class list OK

Don't know why it's not working with smlets...

Regards,
C.
Developer
Mar 4, 2013 at 4:49 PM
It may be that you have installed an SM update which has new libraries.
This is the reason that the SMLets package has the sources, which you should rebuild and use the rebuilt binaries
Mar 4, 2013 at 6:09 PM
Edited Mar 4, 2013 at 6:11 PM
I did rebuild already, just before posting, because smlets seems to be compiled for RTM version and we installed an update. This update was long time ago.

Anyway : I found the problem (or at least a solution) in our environnement : I had to comment the setting of the global variable $smdefaultserver in the smlets module conf file (C:\Program Files\Common Files\SMLets\SMLets.psm1)
#$GLOBAL:smdefaultcomputer = "SCSMSERVERNAME"
Don't know why it wasn't working before I reinstall the smlets, but, anyway, it works now, that's OK.

By the way, I notice that 1 have 2 differents versions on our environnement (Get-SMLetsVersion) :
-preproduction :
TargetProduct       : Microsoft System Center Service Manager SP1
Revision            : unknown
LastChangedRev      : unknown
Changes             : {}
SMCoreVersion       : 7.0.6555.128
SM2012              : False
-production :
TargetProduct       : Microsoft System Center 2012 - Service Manager
Revision            : 74609
LastChangedRev      : 70086
Changes             : {M       WiX/SMLets.X86.msi, M       WiX/SMLets.msi}
SMCompiledVersion   : 7.5.1561.0    
SMInstalledVersion  : 7.0.6555.0
SM2012              : True
As our SCSM serveur is 2010 SP1, I guess this is better to use the version on the preproduction environnement.
Both versions seem to work, but do you think there could be an impact to use 2012 version of smlets to access a 2010 SP1 SCSM server ?

Thanks
C.