Tocano's Posts

Then here's my more rudimentary alternative: $output = @() foreach ($nextDSC in $allDSCs) {     $dscVMs = $nextDSC | Get-VM     foreach ($nextVM in $dscVMs){         $o = New-O... See more...
Then here's my more rudimentary alternative: $output = @() foreach ($nextDSC in $allDSCs) {     $dscVMs = $nextDSC | Get-VM     foreach ($nextVM in $dscVMs){         $o = New-Object System.Object         $o | Add-Member NoteProperty DSC $nextDSC.Name         $o | Add-Member NoteProperty VM $nextVM.Name         $o | Add-Member NoteProperty Cluster ($nextVM | Get-Cluster).Name         $output += $o     } } $output | Export-Csv -Path $outputPath -NoTypeInformation
Blast you LucD. Hit refresh before submitting my own response only to see you've (as usual) beat us all to the punch (and, of course, is probably more efficient too). Leave some crumbs for the... See more...
Blast you LucD. Hit refresh before submitting my own response only to see you've (as usual) beat us all to the punch (and, of course, is probably more efficient too). Leave some crumbs for the rest of us
I started running into this problem when executing unmaps. It would seem that regardless of setting the -WebOperationTimeoutSeconds, the execution would consistently throw an exception at 30 min ... See more...
I started running into this problem when executing unmaps. It would seem that regardless of setting the -WebOperationTimeoutSeconds, the execution would consistently throw an exception at 30 min on the nose. It appears to be the same problem as described here and here‌ (and even mentioned here). I'm curious if there is some workaround that has been publicized in the ~2 years since that problem was described? I'm hoping the recommendation is a new esxcli timeout setting or something I cannot find and not just "have your script actually SSH to the host to call esxcli from the command line". If not, at the very least, is this a recognized issue that they are going to address in a future version? Thank you
True, and I'll play with the profiles. Thank you. If the PowerCLI Team removes it, it would be a change in the behaviour of PowerCLI. I feel like this is already a change from previous be... See more...
True, and I'll play with the profiles. Thank you. If the PowerCLI Team removes it, it would be a change in the behaviour of PowerCLI. I feel like this is already a change from previous behavior (this 'cd \' line is NOT in previous versions of this script until 6.0R2). And if one wanted to avoid changing the current behavior, the 'cd \' could simply be moved a dozen lines earlier (before the custom initialize script inclusion) and not really change behavior while allowing customization to override it. Anyway, I have what I need to work around it. Thank you. I'll stop ranting.
and after the call to this script I do my own CD (in my case to my scripts folder) Doesn't that sort of defeat the purpose of the previous steps? Thanks for the recommendation on push-/... See more...
and after the call to this script I do my own CD (in my case to my scripts folder) Doesn't that sort of defeat the purpose of the previous steps? Thanks for the recommendation on push-/pop-location. I was not familiar with them. Though, this whole thing feels like a bit of unnecessary effort to set one's default directory. I still feel like line 269 should be removed from the default Initialization script - or at least relocated to much earlier in the script. Using push-/pop-location does seem to provide a better option than modifying the default Initialization file. However, this is not as simple in a multi-user environment. Anyway, thank you for the suggestion.
That's a good way to start scripts and set the current working directory. However, it doesn't seem to address setting the default working directory (at startup) of a PowerCLI console as I was ref... See more...
That's a good way to start scripts and set the current working directory. However, it doesn't seem to address setting the default working directory (at startup) of a PowerCLI console as I was referring to. I'll look at some of your scripts. Thanks for sharing.
So this may be a bit pedantic, but I'm sure others understand how you start trying to do something simple and it snowballs into a much larger issue. Well, I wanted to set the default directory... See more...
So this may be a bit pedantic, but I'm sure others understand how you start trying to do something simple and it snowballs into a much larger issue. Well, I wanted to set the default directory I start in when I launch PowerCLI instead of the default C:\. I started with adding a 'cd C:\path\' in a generic Powershell profile file. However, this didn't work. But my normal Powershell consoles were starting in the correct path, so I figured it must be something happening with PowerCLI specifically. So I looked in 'Initialize-PowerCLIEnvironment.ps1' and saw a 'cd \' around line 269 (PowerCLI 6.0R3). This appeared to be the culprit. In accordance with the documentation, instead of modifying the default Initialize file and possibly messing up the signature, I then tried to create a custom 'Initialize-PowerCLIEnvironment_Custom.ps1' file and added 'cd C:\path\' to that. According to the documentation, "The application recognizes and loads the custom file after loading the default script configuration file."  However, again, this didn't work. Looking back at the default Initialize script, I noticed that the 'cd \' is actually located AFTER it runs the custom init script (lines 264-267). So it seems this 'cd \' is pretty much the LAST thing that will run before you get a prompt. So the only option I could find, despite the documentation's warning, was to modify the default Initialize script. Is there a more elegant approach to this I'm overlooking? Why does this set a default directory at all - especially at that point in the initialization? This almost feels like a development line that was supposed to be removed before publishing, but was overlooked.
Just an update to this. I opened a case with VMware who was quite prompt in confirming that this is an issue (though 'bug' may be a misnomer). It is due to the fact that PowerCLI (and specificall... See more...
Just an update to this. I opened a case with VMware who was quite prompt in confirming that this is an issue (though 'bug' may be a misnomer). It is due to the fact that PowerCLI (and specifically the connection manager) are intentionally designed to assume a single 'AppDomain' per PowerCLI instance. This works well most of the time since every individual Powershell console is its own AppDomain. However, ISE uses a single AppDomain for the entire application, even though it creates different runspaces for each PowerShell tab. Because of this, there are collisions between the Powershell tabs in ISE for VIServer connections. They recommend that if one wishes to use ISE, then do so just for script development. Then either use multiple instances of ISE for different vCenters or actually test/execute the scripts in individual Powershell consoles. VMware said they will mark this as an issue, though a low-priority one (thus not demanding a patch or updating older versions of PowerCLI), and will seek to rework this area to fix the issue in an upcoming release. Thank you LucD for helping me confirm this issue.
Are you talking about within the snapshot script or via a different script completely that you would run before you ran the Snapshot script?
Try something like this: $connection = Connect-VIServer -Server 192.168.1.9 -Protocol https $vmNameList = Import-Csv .\path\to\datafile.csv $date = Get-Date $vmObjs = Get-VM -Na... See more...
Try something like this: $connection = Connect-VIServer -Server 192.168.1.9 -Protocol https $vmNameList = Import-Csv .\path\to\datafile.csv $date = Get-Date $vmObjs = Get-VM -Name $vmNameList $output = @() foreach($nextVM in $vmObjs) {     $return = $null     $return = $nextVM | New-Snapshot -Name "Before Epic Upgrade" -description "Before Epic Upgrade Snapshot $date" -quiesce      if($return){ $result = "Success" }      else { $result = "Failure" }      $output += @($nextVM.Name,$result) } $smtpServer = [smtpServer] $emailTo = [destEmailAddr] $emailSubject = "Snapshot Results" $emailBody = "$($output | ft -autosize)" Send-MailMessage -To $emailTo -From 'scriptEmail@noreply.com' -Subject $emailSubject -Body $emailBody -SmtpServer $smtpServer $connection | Disconnect-VIServer -Confirm:$false Probably not the most efficient or elegant approach, but that should do most of what you need.
Our environment uses multiple CustomAttribute annotations on VMs. I've noticed that when I use Get-TagAssignment on VMs in our vCenter, the Entity object, which should be just a VM (VirtualMachin... See more...
Our environment uses multiple CustomAttribute annotations on VMs. I've noticed that when I use Get-TagAssignment on VMs in our vCenter, the Entity object, which should be just a VM (VirtualMachineImpl) object, has a Name which includes all/most of the CustomAttribute annotation names. This occurs regardless of whether I'm doing anything with regard to CustomAttributes or not. I've tested this on multiple vCenters and multiple PowerCLI instances (all 6.0R3) on different computers with similar behavior. I tried searching and I couldn't find any reference to a bug anywhere. Also odd is that some of the VMs seem to have the VM name listed first, then the various CustomAttribute names. Other VMs, however, seem to list the CustomAttribute names first and the VM name at the end. No apparent reason for difference. This feels like a bug, but I want to confirm whether this is something unusual about my environment or whether others are able to reproduce this. Steps to reproduce (assuming standard modules are loaded): > Connect-VIServer [vcenterServer] > $vmTags = Get-VM | Get-TagAssignment > $vmTags Will list Entity as '[CustomField1Name] [CustomField2Name] ... [CustomFieldnName] [VMName]' Interestingly, listing $vmTags.Entity.Name will actually only return the VM Names themselves (without CustomAttribute names). So it's still usable for name matching. If this is something specific to my environment, does anyone have any thoughts on what might be causing it?
Depending on how deeply nested and how common your names are and would require testing, but essentially, yes. If you recreate your folder structure to match your original vCenter, then you can ap... See more...
Depending on how deeply nested and how common your names are and would require testing, but essentially, yes. If you recreate your folder structure to match your original vCenter, then you can apply the permissions to the appropriate folders and as long as propagate is set accordingly, it should inherit to the sub-folders similar to how they were set in the original vCenter. One caveat is that you have to export any custom Roles/Privileges as well.
Not sure that this is the most efficient method, but you might consider adding to the approach of the script to fetch the folder structure (you can reference previous threads on this here, here, ... See more...
Not sure that this is the most efficient method, but you might consider adding to the approach of the script to fetch the folder structure (you can reference previous threads on this here, here, or even here, etc). This way, you can not only recreate your folder structure (which - from the sound of it - contains numerous folders), but by reapplying the explicit permissions you gained from your original script, the permissions will inherit and you should have your entire folder structure recreated - with permissions - programmatically.
If you've already got the data from PowerCLI that you need into the object to export, then I think this is just a generic PowerShell issue. I can point you at resources like the Export-XLSX cm... See more...
If you've already got the data from PowerCLI that you need into the object to export, then I think this is just a generic PowerShell issue. I can point you at resources like the Export-XLSX cmdlet, or you can look at some more generic options like here and here. There are also some resources that speak to setting Excel cells background color. I think using some combination of those resources should provide you what you need to create the more pretty output I think you're looking for.
I can't test and am on my phone, but just a thought - do the folders you are missing in the report actually have permissions applied directly on them or do they simply inherit all their permissio... See more...
I can't test and am on my phone, but just a thought - do the folders you are missing in the report actually have permissions applied directly on them or do they simply inherit all their permissions?
Noticed something interesting with this. ISE tabs to not APPEAR to share PSDrives. In tab 1 I can create and access a PSDrive that I cannot (directly) see or access in tab 2. I can also create a ... See more...
Noticed something interesting with this. ISE tabs to not APPEAR to share PSDrives. In tab 1 I can create and access a PSDrive that I cannot (directly) see or access in tab 2. I can also create a PSDrive in tab 2 with the same name as one created in tab 1 with either the same or different mapping. Each tab appears to be completely distinct and separate runspaces for PSDrives - as is consistent with variables, functions, modules, etc. However, in secondary ISE tabs, when I load the PowerCLI module, I get a small error: > Import-Module VMware.VimAutomation.Core The specified mount name 'vmstores' is already in use. The specified mount name 'vis' is already in use. > So I started looking at mount points and PSDrives for the tabs. On tab 1, after importing the VMware module, it lists a few VMware specific PSDrives - Get-PSDrive lists 'vi','vis','vmstore', and 'vmstores'. However, in tab 2, after importing the module (and getting the above referenced errors), looking at Get-PSDrive lists no such PSDrives. Yet, if I connect to [vCenterServer1] in tab 1 and [vCenterServer2] in tab 2, while the $global:DefaultVIServers in each tab lists only that tab's respective vCenterServer, if I go to tab 1 (where the PSDrives were actually listed) and do a > ls vis: I get BOTH vCenterServers: > ls vis: Name                 Type     Id             ----                 ----     --             [vCenterServer1]@443 VIServer /VIServer=... [vCenterServer2]@443 VIServer /VIServer=... So it appears that the VMware module seems to use both a global variable (that is unique per PS tab/runspace) as well as a PSDrive (regardless of PS tab/runspace) that is created via a method that prevents it from being recreated in other runspaces in order to track vCenter Connections. Could this be using some low-level .Net library to create the mount points and thus is somehow ignoring the PS tab/runspaces? Let me know if you need more explicit steps/details on this.
Right, certainly odd. Of course, the next question is why it behaves differently in multiple ISE tabs vs multiple PS Consoles. :smileyconfused:  My guess would be that it has something to do w... See more...
Right, certainly odd. Of course, the next question is why it behaves differently in multiple ISE tabs vs multiple PS Consoles. :smileyconfused:  My guess would be that it has something to do with the fact that (as I understand it) each individual PS console is a completely separate process whereas each ISE tab is (again, I believe) just a different thread within a single ISE process. I wonder if the Connect-VIServer code has some type of PID lookup/check when a new invocation is executed.
Not sure if this is really relevant, but just noticed the following: In a single PS Console, every Connect-VIServer invocation after the first (to the same server with same credentials), inste... See more...
Not sure if this is really relevant, but just noticed the following: In a single PS Console, every Connect-VIServer invocation after the first (to the same server with same credentials), instead of taking 4-5 seconds, takes about 0.1 seconds (measure-command says about 105-110ms). So I assume that this isn't actually reconnecting to the vCenter server and is instead just recognizing that an existing session to that server with those credentials exists and so just returns that object. In fact, after the first connection, I can completely Remove-Variable the DefaultVIServer(s) variables, rerun the Connect-VIServer, and it still takes only ~100ms. So this makes me think that it's keeping track of server connections elsewhere besides the $global:DefaultVIServer(s) variables. EDIT: Though I realize I could be wrong and it is actually contacting the vCenter server, who sees an existing session, and maybe just returns that already-built session - just all in lightning fast time.
Right. As I noted in my original post, it appears that each tab has its own set of global variables. And when I use Connect-VIServer in two different tabs to two different servers, each tab has i... See more...
Right. As I noted in my original post, it appears that each tab has its own set of global variables. And when I use Connect-VIServer in two different tabs to two different servers, each tab has its own $global:DefaultVIServer variable seemingly set to the appropriate server - as one would expect. However, as soon as I try to actually execute anything (i.e. Get-VM), the error occurs on the oldest invocation of Connect-VIServer while the newest execution always works just fine. Just to confirm, when you say you tested this and it all works for you, you did try steps 9 and 10 in my reproduction steps and execute something (i.e. Get-VM) in each tab and those both work, right? You didn't just confirm the values in the $global:DefaultVIServer(s)?
I had not. However, that seems specific to customizing new ISE basic tabs as "Remote tabs" using Remote PSSessions and avoid loading the PS_ISE profile or not. I don't see anything in there that ... See more...
I had not. However, that seems specific to customizing new ISE basic tabs as "Remote tabs" using Remote PSSessions and avoid loading the PS_ISE profile or not. I don't see anything in there that applies to what I'm seeing with the Connect-VIServer or that speaks to global variables - likely because it doesn't appear that the PSSessions use global variables the way PowerCLI uses the global:defaultviserver(s). I'm currently trying to figure out what - if anything - Connect-VIServer in my current tab changes in the global:defaultviserver(s) variables in another tab. It's a stretch, but we'll see. But this isn't something strange with my setup right? Others have the same issue? [Open ISE] > Connect-VIServer [vCenterServer1] > $allVMs = Get-VM Should succeed ['File' -> 'New Powershell Tab'] > Connect-VIServer [vCenterServer2] > $allVMs = Get-VM Should Succeed [return to Tab 'Powershell 1'] > $allVMs = Get-VM **ERROR**