We want to use DSC to build our test environments (mainly ESX, though there is some Hyper-V usage), and also to run automated tests. Because these are test environments, they all exist in separate domains. When we're done, we want to have a configuration (or set of configurations) which will
And then do the whole thing again the next day with a different build
Right now, though, I am just trying to get a single machine set up in my test domain (I'll worry about creating the domain later). I can ping the machine just fine, and connect with a remote PowerShell session. However, Start-DSCConfiguration is giving me this error:
PS> Start-DscConfiguration -Path .\SqlServerSetup\ -Verbose -Wait VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'. VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'. WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer e1-sql.e1.local. Verify that the computer exists on the network and that the name provided is spelled correctly. + CategoryInfo : NotSpecified: (root/Microsoft/...gurationManager:String) , CimException + FullyQualifiedErrorId : HRESULT 0x80070035 + PSComputerName : e1-sql.e1.local VERBOSE: Operation 'Invoke CimMethod' complete. WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer e1-ev.e1.local. Verify that the computer exists on the network and that the name provided is spelled correctly. + CategoryInfo : NotSpecified: (root/Microsoft/...gurationManager:String) , CimException + FullyQualifiedErrorId : HRESULT 0x80070035 + PSComputerName : e1-ev.e1.local VERBOSE: Operation 'Invoke CimMethod' complete. VERBOSE: Time taken for configuration job to complete is 0.028 seconds
(I'm basically following this example to get my SQL Server set up: https://www.youtube.com/watch?v=cXv7aLiGAus)
I've had stuff working in the past from VM-to-VM, so I think this appears to be because I'm connecting from a different domain.
One thing I did try was copying everything to a VM in that environment and then running Start-DscConfiguration from a remote session. That gave me a different error about the logon session not existing.
Any ideas or suggestions would be appreciated
I might be barking up the wrong tree here, but the two things I would look at are...
1. are you providing a valid credential?
Youtube is throttle at work for use, so I can't really look at the link you posted without it buffering for what seems like half a century.
Hi Stefan, thanks for replying
Don't worry – that was my first thought as well. The credentials (I'm using e1\administrator) and machine address work OK with New-PSSession, so I think they are valid. I've been trying all sorts of things just to confirm my own sanity.
The video is titled "Powershell DSC – Installing SQL Server 2014 on Server Core" by Michael Bird, and shows DSC setting up SQL Server on some Hyper-V VMs, in case those details shed any light.
I guess I'm looking for confirmation that what I describe should work in a universe that makes sense.
In fact one thing I just tried a few minutes ago in a madly random fashion is this
$session = New-CimSession -ComputerName e1-sql.e1.local -Credential e1\administrator Start-DscConfiguration -Path .\SqlServerSetup\ -Verbose -Wait -CimSession $session
This was able to connect and apply the configuration (though I'd stripped the configuration back to just starting notepad – I'm now starting to add everything back in so it does something useful).
So, what you're trying to do should work – but when you're crossing domain boundaries, the authentication can get a little tricky. It's not necessarily enough to just specify a domain\user, because by default only Kerberos is available on the receiving machine, and it won't just take a domain/user. Although you're not using Remoting, you're using the same underlying WS-MAN protocol as Remoting, so the advice in "Secrets of PowerShell Remoting" would still in large part apply. It's on our eBooks menu – free.
I'll be sure to take a look at that eBook.
Using -CimSession seems to work just fine. I think by default it tries to find out information about the machine in order to build a session object, and it's a little overly fussy about being able to resolve that information by querying the domain. But if you give it a properly constructed CIM session object, it's happy with that so it gets around the issue.
This might mean the stuff wrapping the configuration gets a little more interesting.
Thanks very much to both you and Stefan for your help
You must be logged in to reply to this topic.