I have created a simple DSC script which is the standard one I assume for downloading IIS.
configuration IISInstall
{
node VISUALSTUDIOVM
{
WindowsFeature IIS
{
Ensure = "Present"
Name = "Web-Server"
}
}
}
I am trying to create an Azure virtual machine from Powershell.
What I do is:
I upload this configuration file to my azure storage account.
Publish-AzureVMDscConfiguration -ConfigurationPath C:\AzureVirtualNetwork\Installiis.ps1 -StorageContext $context -Force
I create a $vm variable and set the DSC extension
$vm = Set-AzureVMDSCExtension -VM $vm -ConfigurationArchive "Installiis.ps1.zip"
I then update the $vm
$vm | Update-AzureVM
I get the operation success message, but the IIS does not get installed on the machine.
Am I missing something. The $vm I create is Windows server 2012 R2 machine.
The same DSC script when I run from after creating my machine using Start-DscConfiguration and specifying the MOF path it works fine.
The log on the target machine is as follows:
When I check the log file , I get this error, what needs to be done
[01/14/2015 23:34:20.81] Executing: C:\Packages\Plugins\Microsoft.Powershell.DSC\1.5.0.0\bin\enable.cmd
[01/14/2015 23:34:23.14] Execution Complete.
#
Execution Output:
VERBOSE: Verifying OS Version...
VERBOSE: OS Version: 6.3.9600.0
VERBOSE: Server OS: True
VERBOSE: OS is supported; enabling extension.
Execution Error:
C:\Packages\Plugins\Microsoft.Powershell.DSC\1.5.0.0\bin\enable.ps1 : Error enabling the DSC Extension: The DSC Extension was
not installed correctly, please check the logs on the VM.
At C:\Packages\Plugins\Microsoft.Powershell.DSC\1.5.0.0\bin\pre-enable.ps1:51 char:5
+ & $scriptRoot\enable.ps1 -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,enable.ps1
#
Command C:\Packages\Plugins\Microsoft.Powershell.DSC\1.5.0.0\bin\enable.cmd of Microsoft.Powershell.DSC has exited with Exit code: 0
plugin (name: Microsoft.Powershell.DSC, version: 1.5.0.0) completed successfully.
Two things I would recommend:
#kevmar is correct, the node localhost is correct
Try a later O/S version. The O/S your on is running 1.5.0.0 of the DSC extension although there is at least 1.9.0.0 version. Try a guest VM image -ImageName 'a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201502.01-en.us-127GB.vhd' or later.
I would also check the name of you .zip file in your storage container. Azure storage uses lowercase. when you run the command:
$vm = Set-AzureVMDSCExtension -VM $vm -ConfigurationArchive "Installiis.ps1.zip"
change the .zip name to "installiis.ps1.zip"
Related
I need hyper-v inside a docker container using the image mcr.microsoft.com/windows/servercore:ltsc2019-amd64. When I to enable it by using Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart it fails with:
Install-WindowsFeature : The request to add or remove features on the specified server failed.
Installation of one or more roles, role services, or features failed.
The source files could not be found.
Use the "Source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see
http://go.microsoft.com/fwlink/?LinkId=243077. Error: 0x800f081f
At line:1 char:1
+ Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (#{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exception
+ FullyQualifiedErrorId : DISMAPI_Error__Failed_To_Enable_Updates,Microsoft.Windows.ServerManager.Commands.AddWindowsFeatureCommand
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
False No Failed {}
But if I install this role Install-WindowsFeature -Name Hyper-V-PowerShell -IncludeManagementTools
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No NoChangeNeeded {}
it works perfectly. Is there a hardware / nested virtualization requirement that I'm not aware of?
Hyper-V is not supported inside of Windows containers and for that reason the bits for its installation were removed. That's why the first command gives you an error.
The second feature you are installing is the PowerShell module for Hyper-V. That module allows you to manage a Hyper-V node from PowerShell - which you can do from a Windows container, hence the success output.
PS C:\Users\Microsoft> Get-WindowsFeature -Name *hyper*
Display Name Name Install State
------------ ---- -------------
[ ] Hyper-V Hyper-V Available
[ ] Hyper-V Management Tools RSAT-Hyper-V-Tools Available
[ ] Hyper-V GUI Management Tools Hyper-V-Tools Available
[ ] Hyper-V Module for Windows PowerShell Hyper-V-PowerShell Available
If you don't mind me asking: what is the scenario that requires you to have Hyper-V installed in a Windows container?
I'm pretty new to TFS and I'm still learning how to use it (so hopefully this isn't just a stupid oversight on my end). I'm working an internship this summer at a seasonal developer position, and essentially my end goal is to automate load testing for the company's website. I'm using TFS to achieve this goal; the build I currently have has two tasks only right now: one to start the controller and the testing environment, and one to stop them. My problem is that the build keeps failing before it really even starts, due to a "term not recognized" error on line 1, specifically caused by what appears to be the default working folder not being recognized.
Here are the relevant log files:
2019-05-30T20:00:02.0942883Z Executing the following powershell script. (workingFolder = D:\RM_agent\_work\11\s)
2019-05-30T20:00:02.0942883Z D:\RM_agent\_work\11\s
2019-05-30T20:00:02.4999117Z ##[error]. : The term 'D:\RM_agent\_work\11\s' is not recognized as the name of a
2019-05-30T20:00:02.4999117Z ##[error]cmdlet, function, script file, or operable program. Check the spelling of the
2019-05-30T20:00:02.4999117Z ##[error]name, or if a path was included, verify that the path is correct and try again.
2019-05-30T20:00:02.4999117Z ##[error]At line:1 char:3
2019-05-30T20:00:02.4999117Z ##[error]+ . 'D:\RM_agent\_work\11\s'
2019-05-30T20:00:02.4999117Z ##[error]+ ~~~~~~~~~~~~~~~~~~~~~~~~
2019-05-30T20:00:02.4999117Z ##[error] + CategoryInfo : ObjectNotFound: (D:\RM_agent\_work\11\s:String)
2019-05-30T20:00:02.4999117Z ##[error] [], CommandNotFoundException
2019-05-30T20:00:02.4999117Z ##[error] + FullyQualifiedErrorId : CommandNotFoundException
I know that the working folder defaults to $(Build.SourcesDirectory), so I'm assuming that D:\RM_agent\_work\11\s is what $(Build.SourcesDirectory) evaluates to. RM_agent is obviously an agent, so /_work/11/s should be the local path where it stores the source code. Why is it unrecognized then?
I tried manually setting the working folder for the scripts through tfs to the folder where the build is stored, but the build still failed and the logs still showed that workingFolder = D:\RM_agent\_work\11\s.
Additionally, the line of code that the build is failing on, Executing the following powershell script. (workingFolder = D:\RM_agent\_work\11\s), is nowhere in the script I am trying to execute, which confuses me. Where is this script coming from?
(I can remove this if it doesn't fit the guidelines/is off topic, but if anyone could point me towards any resources about tfs and/or load testing it would be massively helpful as well)
EDIT: Here is the powershell script for the first task
########################################
# start environment
########################################
# import modules
Import-Module '\\neenah-san1\TSbuild\Deployment\Tools\PowerShell\Azure\JJK.TS.Azure.psm1' -Force -Prefix 'TS'
# provide azure credentials
$credential = Get-Credential
# login to azure subscription
Login-AzureRmAccount -Credential $credential
# start the controller
Get-AzureRmVM -ResourceGroupName 'TS-LoadTest-TST' | Where-Object {$_.Name -match 'vstc'} | Start-TSAzureVM -Credential $credential
# wait for controller to fully start
Start-Sleep -Seconds 120
# start the agents
Get-AzureRmVM -ResourceGroupName 'TS-LoadTest-TST' | Where-Object {$_.Name -match 'vsta'} | Start-TSAzureVM -Credential $credential
# check status of all servers
Get-AzureRmVM -ResourceGroupName 'TS-LoadTest-TST' -Status | Sort-Object -Property Name | Select-Object -Property Name, PowerState | Format-Table -AutoSize
Solution structure:
EDIT 2: [RESOLVED] It's all fixed now, thank you! I went into the repository and mapped the folder my scripts were in directly to $(build.sourcesDirectory). Consequently I was able to change the file path to $(build.sourcesDirectory)\StartControllerAndAgents.ps1 and the build is now able to find the files to run.
You need to specify the path to the script as $(Build.SourcesDirectory)\Path\To\Script. Not the TFVC path which you've configured now $/Project/Path/To/Script.
The exact path depends on the workspace mapping of the build definition.
The same applies to the working directory.
There are a number of variables in Azure Pipelines (the current name for the Build hub in TFS/Azure DevOps) that resolve to different standardized paths on the agent. Almost all tasks take a relative path off of those variables.
I have a scheduled task which runs an exported function from my PowerShell module which is hosted at powershellgallery.com. The function performs a check against the built-in PSGallery repository to see if a newer version is available and if so, update it.
I've noticed my module is not being updated as it should and to troubleshoot the issue I've redirected the output from two separate commands. First, to make sure the repository is 'visible' to the SYSTEM account running the task I run:
Get-PSRepository *>> c:\repo.log
This yields the following output:
Name InstallationPolicy SourceLocation
---- ------------------ --------------
PSGallery Untrusted https://www.powershellgallery.com/api/v2
So the SYSTEM account running the function as a scheduled task can 'see' the repo; no problem. Next, the function runs the Update-Module command as such:
Update-Module -Name $ProductName -Confirm:$false -Force -Verbose *>> c:\update.log
This yields the following output:
Checking for updates for module '[removed by me]'.
PackageManagement\Install-Package : Unable to find repository 'https://www.powershellgallery.com/api/v2/'. Use
Get-PSRepository to see all available repositories.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.0.4\PSModule.psm1:12546 char:20
+ ... $sid = PackageManagement\Install-Package #PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Ex
ception
+ FullyQualifiedErrorId : SourceNotFound,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage
Lastly, I checked the module to make sure it is indeed associated with PSGallery by running:
Get-InstalledModule -Name $ProductName | fl
The output shows:
RepositorySourceLocation : https://www.powershellgallery.com/api/v2/
Repository : PSGallery
UPDATE: I decided to use the Install-Module with the -Force switch to 'update' the module instead as I couldn't get the other command to work. Oddly though, when I do a Get-InstalledModule -AllVersions I can clearly see a difference between a module installed interactively and one installed under the SYSTEM account (running as a scheduled task). Pay attention to the Repository column:
If I run the function interactively it works without issue.
If I run Find-Module -Name $ProductName from within the function it finds the module without issue.
Tried both solutions from other question to no avail...
Any idea why the Update-Module command can't find the repo??
I believe you are seeing the bug described in https://github.com/PowerShell/PowerShellGet/issues/349 . It's not really related to SYSTEM account. Simplest workaround until fixed version is released is to uninstall the module then reinstall it again. You should only have to do that once, and update-module should work thereafter.
UPDATE: This is resolved in newer builds of PowerShellGet.
I'm trying to create my first DSC pull configuration. My node server can read its .mof files if I store them in a directory on the node server, but it can't access its configuration .mof from a configuration-repository-folder because it seems to not have read-permissions to that folder where the .mof and .mof.checksum files are. This might be a result of the fact that the LCM of a node server by default uses the local-SYSTEM-credentials, and not the user login credentials. I cannot set the LCM credential value.
The pull server is up and running (confirmed). The .mof and .checklist.mof files are stored in a network shared folder "\myNetworkShares\DSC-Configs".
Here is how I configure the LCM of my node server, where I set the credential of the ConfigurationRepositoryShare
[DSCLocalconfigurationManager()]
Configuration LCM_CLIENT_PULL
{
Node $AllNodes.NodeName
{
Settings {
AllowModuleOverwrite = $True
ConfigurationMode = 'ApplyAndAutoCorrect'
RefreshMode = 'Pull'
ConfigurationID = $node.Guid
CertificateID = $node.ThumbPrint
}
ConfigurationRepositoryShare DSCSMB {
Credential = $node.Credential
Sourcepath = "\\myNetworkShares\DSC-Configs"
}
}
}
I attempt to invoke my node server to run its configs by typing
Update-DscConfiguration -ComputerName myNodeServerName -Wait -Verbose
And I receive an error: (NOTE: error doesn't occur when .mof is stored in a directory on my node server, to which it has read permissions!)
The file \\myNetworkShares\DSC-Configs\name.mof is not found.
+ CategoryInfo : ObjectNotFound: (\\myNetworkSha...name.mof:String) [], CimException
+ FullyQualifiedErrorId : DSCFileFileNotFound,Microsoft.PowerShell.DesiredStateConfiguration.DownloadManager.FileGetAct
ionCommand
+ PSComputerName : myNodeServerName
I'm trying to change the credential attribute so that my node server can access the config .mof file, by including my credentials in the following line of code:
Set-DSCLocalConfigurationManager -ComputerName myNodeServerName -Path c:\LocationOfMyNodeMetaDataMofFile –Verbose -Credential $myCreds
However, the credential attribute never appear as populated. How can I change the credential attribute of the LCM on my node server???
link to LCM config image
More notes:
I'm avoiding the encryption temporarily by allowing plain text password in the pull-node LCM-configuration .meta.mof file.
I can see that the credential was written to the myNodeServer.meta.mof file before using Set-DSCLocalConfigurationManager
There is a known issue with the credential parameter in a file based pull server. Can you try setting it up with read access for everyone as described in this blog http://nanalakshmanan.com/blog/Push-Config-Pull-Module/
Short story: I get the following error when trying to create a namespace on Azure Service Bus using Azure Powershell (Run as Administrator):
PS C:> New-AzureSBNamespace -Name mynewnamespace2 -Location "East US"
-CreateACSNamespace $true -Namespac New-AzureSBNamespace : Object reference not set to an instance of an object. At line:1 char:1
+ New-AzureSBNamespace -Name mynewnamespace2 -Location "East US" -CreateACSNamespace $ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [New-AzureSBNamespace], NullReferenceException
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceBus.NewAzureSBNamespaceCommand
Long story: I created a first namespace in Azure Service Bus to use Relay in buffered mode (namespace=mynewnamespace). It works great except when you want to transfer a larger set of data. For this there is the streamed mode and I found this handy example (https://code.msdn.microsoft.com/How-to-send-a-large-c36ab70e), changed appropriate settings for namespace and credentials and ran the server part from the project and I get the error
{"The remote name could not be resolved:
'mynewnamespace-sb.accesscontrol.windows.net'"}
because, of course, this ACS namespace does not exist. So I found out that I need to create the namespace the old fashioned way using PS, installed Azure CLI and run the commands below with the following result:
For a list of all Azure cmdlets type 'get-help azure'.
For a list of Windows Azure Pack cmdlets type 'Get-Command wapack'.
PS C:> azure login
info: Executing command login
|info: To sign in, use a web
browser to open the page https://aka.ms/devicelogin. Enter the code EE226448L to
authenticate. If you're signing in as an Azure AD application, use the
--username and --password parameters.
/info: Added subscription Visual Studio Enterprise with MSDN info: Setting subscription
"Visual Studio Enterprise with MSDN" as default
info: login command OK
PS C:> New-AzureSBNamespace -Name mynewnamespace2 -Location "East US" -CreateACSNamespace $true -NamespaceType Messaging
WARNING: Microsoft Azure PowerShell collects data about how users use
PowerShell cmdlets and some pro encounter. Microsoft uses this
information to improve our PowerShell cmdlets. Participation is volu
choose to participate your device automatically sends information to
Microsoft about how you use Azure Powershell.
If you choose to participate, you can stop at any time by using Azure
PowerShell as follows:
1. Use the Disable-AzureDataCollection cmdlet to turn the feature Off. The cmdlet can be found in the AzureResourceManager module To disable
data collection: PS > Disable-AzureDataCollection
If you choose to not participate, you can enable at any time by using
Azure PowerShell as follows:
1. Use the Enable-AzureDataCollection cmdlet to turn the feature On. The cmdlet can be found in the AzureResourceManager module To enable
data collection: PS > Enable-AzureDataCollection
Select Y to enable data collection [Y/N]: WARNING: You choose not to
participate in Microsoft Azure PowerShell data collection. WARNING:
The setting profile has been saved to the following path
'C:\Users\PDube\AppData\Roaming\Windows Azure Powershell\AzureDataCollectionProfile.json'.
New-AzureSBNamespace :
Object reference not set to an instance of an object. At line:1 char:1
+ New-AzureSBNamespace -Name mynewnamespace2 -Location "East US" -CreateACSNamespace $ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [New-AzureSBNamespace], NullReferenceException
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceBus.NewAzureSBNamespaceCommand
I tried to create the new namespace using Azure CLI on 2 different computers, thinking the first install was corrupted, but I get the exact same error.
How can I fix this error?