<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>NFerrar Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>NFerrar Tracker</description>
    <pubDate>Wed, 15 Nov 2023 09:40:16 GMT</pubDate>
    <dc:date>2023-11-15T09:40:16Z</dc:date>
    <item>
      <title>Full backup of vCenters in ELM?</title>
      <link>https://communities.vmware.com/t5/VMware-vCenter-Discussions/Full-backup-of-vCenters-in-ELM/m-p/2975702#M48640</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;How are people taking fully recoverable backups of their vCenters (v7) that are in ELM? We currently just do file-based backups to an SFTP server but there's a limitation that this method doesn't backup the directory DB. So although for a single vCenter failure we could do the standard deploy fresh and restore the file-based backup to it (and resync with the other vCenters directory DB) if we had a directory DB issue and the vsphere.local SSO domain itself became corrupt (or someone maliciously deleted contents etc.) we would have no way to restore to a previous copy.&lt;/P&gt;&lt;P&gt;Obviously before certain config changes and upgrades you can/should cold snapshot all the vCenters in ELM but that doesn't help with protecting against routine issues with the directory DB (or even just deleted credentials within it). Granted, I've never seen the directory DB just corrupt but I'm guessing it's not an impossibility&lt;/P&gt;&lt;P&gt;My specific case is part of a VCF on VxRail deployment and there's a lot of hooks into the directory DB so I wouldn't want to try redeploying vCenters and trying to recreate all the vsphere.local users and roles created during VCF deployment. I guess we could look at doing an LDAP export but I'm not sure if that's supported as a restore option (and what exactly we can export when doing that)&lt;/P&gt;</description>
      <pubDate>Tue, 04 Jul 2023 09:10:34 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vCenter-Discussions/Full-backup-of-vCenters-in-ELM/m-p/2975702#M48640</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2023-07-04T09:10:34Z</dc:date>
    </item>
    <item>
      <title>Re: VCF Offline Upgrade - the upgrade button disappears after uploading the manifest</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/VCF-Offline-Upgrade-the-upgrade-button-disappears-after/m-p/2970271#M1356</link>
      <description>&lt;P&gt;Just resurrecting this to say thanks for posting the solution, I just had the same issue with a 4.4.0.0 to 4.5.1.0 upgrade and after trying a few other things (working with VMware Support via an SR) but not managing to find a solution I stumbled across this thread. Hopefully VMware will now finally update the documentation!&lt;/P&gt;</description>
      <pubDate>Thu, 25 May 2023 13:16:11 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/VCF-Offline-Upgrade-the-upgrade-button-disappears-after/m-p/2970271#M1356</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2023-05-25T13:16:11Z</dc:date>
    </item>
    <item>
      <title>Re: Deployments from vRSLCM fail due to vCenter permissions</title>
      <link>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Deployments-from-vRSLCM-fail-due-to-vCenter-permissions/m-p/2959676#M263</link>
      <description>&lt;P&gt;But SDDC Manager creates the role itself in vCenter when you deploy vRSLCM from it, it's not one you create manually. That role has extensive permissions but not the same amount as the administrator role has. I don't think anything has gone wrong as such (we see the same issue on 4 separate VCF environments we've deployed) it's just the role doesn't have the rights it needs when vRSLCM is deploying vRealize Suite products (using the integration user that is assigned the "vRealize Suite Lifecycle Manager to vSphere Integration" role (this is as per design decision&amp;nbsp;&lt;SPAN&gt;VCF-VRS-vRSLCM-SEC-003 &amp;amp;&amp;nbsp;VCF-VRS-vRSLCM-SEC-004&amp;nbsp;@&amp;nbsp;&lt;A href="https://docs.vmware.com/en/VMware-Cloud-Foundation/4.4/vcf-vrslcm-wsa-design/GUID-5D3C7EF6-8185-48F7-BF37-DCBC242AF7A6.html" target="_blank"&gt;vRealize Suite Lifecycle Manager Design Decisions (vmware.com)&lt;/A&gt;)&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;We've not deployed/upgraded to v4.5 yet so possibly the custom role is created with additional permissions in that version but the documentation wording seems to be the same as for v4.4&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;In reality it's not often we deploy products through vRSLCM so it's minimal hassle to temporarily change the vRSLCM-to-vSphere integration user to have the administrator role when we do and then change it back after. It just caused confusion when we first encountered the issue and I've not come across it documented in a KB or VMware's VCF deployment docs (which&amp;nbsp;are generally&amp;nbsp;excellent) but possibly I've missed it. Our deployments are VCF on VxRail but I don't think that's relevant for this issue.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 17 Mar 2023 08:58:42 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Deployments-from-vRSLCM-fail-due-to-vCenter-permissions/m-p/2959676#M263</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2023-03-17T08:58:42Z</dc:date>
    </item>
    <item>
      <title>Re: Deployments from vRSLCM fail due to vCenter permissions</title>
      <link>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Deployments-from-vRSLCM-fail-due-to-vCenter-permissions/m-p/2959663#M260</link>
      <description>&lt;P&gt;But why does the deployment process create a new role in vCenter for the user if that role doesn't have the permissions the user needs? Even if that role provides the correct permissions for 99% of operations it should at least be documented for deployment operations you need to grant it the administrator role in vCenter first (I'm not aware that's documented anywhere).&lt;/P&gt;</description>
      <pubDate>Fri, 17 Mar 2023 07:46:33 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Deployments-from-vRSLCM-fail-due-to-vCenter-permissions/m-p/2959663#M260</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2023-03-17T07:46:33Z</dc:date>
    </item>
    <item>
      <title>Re: Query about vRealize Suite Lifecycle Manager appliance placement in second site VCF deployment</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Query-about-vRealize-Suite-Lifecycle-Manager-appliance-placement/m-p/2959054#M1298</link>
      <description>&lt;P&gt;That's not the case for a second site though (that will be federated with another site), the cross-region vRS products are all managed via vRSLCM in the primary site, it's just vRLI (on a local site AVN) that would be in vRSLCM. It basically comes down to SDDC Manager not being multi-site aware so assumes you're always just doing a standard vRSLCM&lt;/P&gt;&lt;P&gt;In the end for our deployment, on the advice of VMware, we didn't deploy a vRSLCM in the second site (apparently they're going to update their design guidance to reflect this), for the the second site you just create a new environment in the primary site's vRSLCM and install vRLI from there.&lt;/P&gt;&lt;P&gt;(this updated advice from VMware was off the back of me querying how I allow for AD authentication to the second site vRSLCM as unless you add the second site standalone/local WOA/vIDM into it there's no way of doing it and the design guidance only covers adding the cross-region WOA/vIDM into vRSLCM but that's already been added into the primary site's vRSLCM)&lt;/P&gt;</description>
      <pubDate>Tue, 14 Mar 2023 09:19:37 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Query-about-vRealize-Suite-Lifecycle-Manager-appliance-placement/m-p/2959054#M1298</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2023-03-14T09:19:37Z</dc:date>
    </item>
    <item>
      <title>Re: Should SDDC Manager surface errors from the underlying vCenter servers?</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Should-SDDC-Manager-surface-errors-from-the-underlying-vCenter/m-p/2959052#M1297</link>
      <description>&lt;P&gt;SDDC Manager's main function is the overall LCM of VCF rather than it's day-to-day management. In theory you could use it as the initial entry point for doing most things within VCF but that's only because it has hyperlinks off to the real management consoles like vCenter. Post-bring-up/initial configuration I rarely go into SDDC Manager and wouldn't see much point in alerts (outside of LCM operations) being sent there.&lt;/P&gt;</description>
      <pubDate>Tue, 14 Mar 2023 09:08:11 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Should-SDDC-Manager-surface-errors-from-the-underlying-vCenter/m-p/2959052#M1297</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2023-03-14T09:08:11Z</dc:date>
    </item>
    <item>
      <title>Re: Error lcmvidm74055</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Error-lcmvidm74055/m-p/2940504#M1222</link>
      <description>&lt;P&gt;Did running the postgres commands fix the node showing status DOWN? (I had a similar issue and step 3 of that KB article fixed the node DOWN issue for me). I haven't seen error&amp;nbsp;&lt;SPAN&gt;LCMVIDM74055 but for other similar codes I've had to log an SR case with VMware as there's very little (if anything) comes up about them just through googling.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Thu, 24 Nov 2022 16:04:23 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Error-lcmvidm74055/m-p/2940504#M1222</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-11-24T16:04:23Z</dc:date>
    </item>
    <item>
      <title>Undo NSX-T federation or create AVNs post federation?</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Undo-NSX-T-federation-or-create-AVNs-post-federation/m-p/2940436#M1221</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;We're deploying VCF v4.4.1 at the moment and have inadvertently done the NSX-T Federation config before having created the AVNs in SDDC Manager for the second site (site B).&lt;/P&gt;&lt;P&gt;I've raised an SR requesting help but thought I'd check here to...&lt;/P&gt;&lt;P&gt;Is there a way to add AVNs post-NSX-T Federation and if not is there a clean way to de-federate (if we have to redeploy NSX-T Global Managers in site B that's not a problem but if we end up breaking AVNs etc. in site A where we already have vRealize Suite components configured it would be a major issue...)&lt;/P&gt;</description>
      <pubDate>Thu, 24 Nov 2022 11:00:09 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Undo-NSX-T-federation-or-create-AVNs-post-federation/m-p/2940436#M1221</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-11-24T11:00:09Z</dc:date>
    </item>
    <item>
      <title>Query about vRealize Suite Lifecycle Manager appliance placement in second site VCF deployment</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Query-about-vRealize-Suite-Lifecycle-Manager-appliance-placement/m-p/2934728#M1196</link>
      <description>&lt;P&gt;We're about to deploy a second VCF site (to federate with an existing site) and the placement of the vRSLCM appliance confuses me. VMware docs state:&amp;nbsp;&lt;/P&gt;&lt;P&gt;In each VMware Cloud Foundation instance, a vRealize Suite Lifecycle Manager appliance deployed on the cross-instance NSX segment&lt;/P&gt;&lt;P&gt;But I don't understand why, surely it would be better to have it in the Reg_B AVN as it will never move between sites? Has anyone deployed it in the Reg_B AVN instead of the X-Reg AVN - is it supported that way? I'm not sure if the VMware docs are a statement or recommendation.&amp;nbsp;&lt;A href="https://docs.vmware.com/en/VMware-Cloud-Foundation/4.4/vcf-vrslcm-wsa-design/GUID-D59D9A51-F829-4472-9683-84185A790E9C.html" target="_blank"&gt;https://docs.vmware.com/en/VMware-Cloud-Foundation/4.4/vcf-vrslcm-wsa-design/GUID-D59D9A51-F829-4472-9683-84185A790E9C.html&lt;/A&gt;&amp;nbsp;(last text box section under "Multiple VMware Cloud Foundation Instances" column&lt;/P&gt;</description>
      <pubDate>Fri, 21 Oct 2022 09:49:18 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Query-about-vRealize-Suite-Lifecycle-Manager-appliance-placement/m-p/2934728#M1196</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-10-21T09:49:18Z</dc:date>
    </item>
    <item>
      <title>Re: vCloud Foundation Federation Limitations</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/vCloud-Foundation-Federation-Limitations/m-p/2931332#M1173</link>
      <description>&lt;P&gt;Worth checking with VMware (TAM or support call) about the two regions, I only see that mentioned in v4.3 docs so maybe it no longer applies?&lt;/P&gt;&lt;P&gt;We haven't done federation yet (but are due to shortly) but only have two regions and a single Management + VI WLD in each so are within the limits. Even if we had multiple VI WLDs we would generally just have them sharing an NSX Manager - it sounds like you have multiple VI WLDs within a deployment and each has a dedicated NSX Manager?&lt;/P&gt;</description>
      <pubDate>Fri, 30 Sep 2022 08:06:54 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/vCloud-Foundation-Federation-Limitations/m-p/2931332#M1173</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-09-30T08:06:54Z</dc:date>
    </item>
    <item>
      <title>Re: VCF 4.4.0.0 - possible to move vRA deployment from VCF vLCM?</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/VCF-4-4-0-0-possible-to-move-vRA-deployment-from-VCF-vLCM/m-p/2931329#M1172</link>
      <description>&lt;P&gt;I'm not really sure what you're asking here. Why do you need to unregister vRA from your current VCF integrated vRSLCM to an independent vRSLCM? You certainly don't need to deploy an independent vRSLCM just to keep using vRS products within a VCF deployment post v4.4.x&lt;/P&gt;&lt;P&gt;You can upgrade you current vRSLCM separately from VCF, check out this KB for supported versions:&amp;nbsp;&lt;A href="https://kb.vmware.com/s/article/88829" target="_blank"&gt;https://kb.vmware.com/s/article/88829&lt;/A&gt;&lt;/P&gt;&lt;P&gt;If I was in your situation I'd open a support case with VMware, stating exact versions of VCF &amp;amp; vRS products you have now and where you want to end up and ask that they provide you with the upgrade path you should follow (they've done this for me in the past).&lt;/P&gt;&lt;P&gt;Any reason you can't just upgrade to VCF v4.4.1.1 now as well (to ensure you're on the latest version) or are you holding off on more upgrades until v4.5 (or whatever version it will be that includes vSphere 8)? Personally I'd get current first - especially if your VCF is Internet connected so pulling down updates is trivial (I work in a dark site so updating is a bit more hassle).&lt;/P&gt;&lt;P&gt;vIDM seems to be the odd-one-out product in that you get stuck with v3.6.2 (I think that's the correct version, not in a place I can double check at the moment). I can't remember if I've applied any minor patches but essentially it's the one product that seems to have been left behind in the VCF world - I'm assuming there's a reason they don't support Workspace ONE Access yet (despite calling it that in their VCF documentation) but I'm not imagining there will be any significant vIDM updates before the transition to WSA happens. I'm not sure WSA is available as an 'all in one' appliance yet which is possibly the reason they've had to stick with vIDM.&lt;/P&gt;&lt;P&gt;We recently did a fresh v4.4.0 deployment and then upgraded to v4.4.1 before deploying vRSLCM v8.6.2 psp 2, patching it to psp 3 then upgrading it to v8.7 (bit strange but it was an 'on VxRail' deployment and we'd contracted Dell for v4.4.0). VMware's advice at the time was to stick with vRSLCM v8.7 even though v8.8 was supported - not sure if that advice has changed since)&lt;/P&gt;</description>
      <pubDate>Fri, 30 Sep 2022 07:52:13 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/VCF-4-4-0-0-possible-to-move-vRA-deployment-from-VCF-vLCM/m-p/2931329#M1172</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-09-30T07:52:13Z</dc:date>
    </item>
    <item>
      <title>Viewing Locker passwords annoying issue</title>
      <link>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Viewing-Locker-passwords-annoying-issue/m-p/2927074#M251</link>
      <description>&lt;P&gt;Why does the vRSLCM UI not provide a better warning if you try and view a Locker password when not logged on as the admin@local account (or &lt;A href="mailto:vcfadmin@local" target="_blank"&gt;vcfadmin@local&lt;/A&gt;&amp;nbsp;in mycase)?&lt;/P&gt;&lt;P&gt;It just errors with "Failed to validate root password. Provide correct root password to authorize this action" but it's not an issue with the root password it's the account you've logged into vRSLCM with that's the problem.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 02 Sep 2022 14:12:09 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Viewing-Locker-passwords-annoying-issue/m-p/2927074#M251</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-09-02T14:12:09Z</dc:date>
    </item>
    <item>
      <title>When do new password complexity requirements in vsphere.local policy apply?</title>
      <link>https://communities.vmware.com/t5/VMware-vCenter-Discussions/When-do-new-password-complexity-requirements-in-vsphere-local/m-p/2926433#M46264</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;I'm trying to understand why an issue occurred with credentials for an account in the vsphere.local domain. I can first see issues in logs occurring 83 days after the account was created so that doesn't tie-in with it expiring (either with the default 90 days or amended 180 day policy we now have). I've also confirmed the recorded password matched what was trying to be used and that it wasn't locked out.&lt;/P&gt;&lt;P&gt;So the only thing I can think of is the original password doesn't match our revised policy's complexity requirements, however I thought complexity rules were only checked during a password change but are they actually checked on use as well? I don't have a record of when the revised password policy was implemented but it would be in the rough time frame when the issue first occurred.&lt;/P&gt;&lt;P&gt;The invalid credentials issue is resolved now, I'm just curious why it happened in the first place!&lt;/P&gt;</description>
      <pubDate>Tue, 30 Aug 2022 12:39:03 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vCenter-Discussions/When-do-new-password-complexity-requirements-in-vsphere-local/m-p/2926433#M46264</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-08-30T12:39:03Z</dc:date>
    </item>
    <item>
      <title>Re: VCF API and postman</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/VCF-API-and-postman/m-p/2916553#M1131</link>
      <description>&lt;P&gt;This is handy to if you want to pull all the SDDC Manager APIs into Postman:&amp;nbsp;&lt;A href="https://my-cloudy-world.com/2021/09/17/create-vmware-cloud-foundation-api-collection-in-postman/" target="_blank"&gt;Create VMware Cloud Foundation API Collection in Postman – My Cloudy World (my-cloudy-world.com)&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 29 Jun 2022 11:49:05 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/VCF-API-and-postman/m-p/2916553#M1131</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-06-29T11:49:05Z</dc:date>
    </item>
    <item>
      <title>Re: Deployments from vRSLCM fail due to vCenter permissions</title>
      <link>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Deployments-from-vRSLCM-fail-due-to-vCenter-permissions/m-p/2909620#M243</link>
      <description>&lt;P&gt;We just give it admin rights before doing any deployments from vRSLCM (and probably will for upgrades in future) and then return it to it's custom role afterwards. I should probably raise an SR for it...&lt;/P&gt;</description>
      <pubDate>Wed, 18 May 2022 06:25:58 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Deployments-from-vRSLCM-fail-due-to-vCenter-permissions/m-p/2909620#M243</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-05-18T06:25:58Z</dc:date>
    </item>
    <item>
      <title>Re: ESXI certificate</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/ESXI-certificate/m-p/2909228#M281638</link>
      <description>&lt;P&gt;Correct - just do the renew part (unless your VCSA certs (MACHINE_SSL_CERT and Trusted_Root) are expiring as well, not just the ESXi hosts)&lt;/P&gt;</description>
      <pubDate>Mon, 16 May 2022 11:59:42 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/ESXI-certificate/m-p/2909228#M281638</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-05-16T11:59:42Z</dc:date>
    </item>
    <item>
      <title>Re: Certificate Generation Utility for VMWare</title>
      <link>https://communities.vmware.com/t5/Skyline-Health-Diagnostics-SHD/Certificate-Generation-Utility-for-VMWare/m-p/2902442#M332</link>
      <description>&lt;P&gt;The version of certgen I've used is available as an attachment here:&amp;nbsp;&lt;A href="https://kb.vmware.com/s/article/85527" target="_blank"&gt;https://kb.vmware.com/s/article/85527&lt;/A&gt;&amp;nbsp;but that was part of a VCF deployment, not sure if there's other versions&lt;/P&gt;</description>
      <pubDate>Tue, 05 Apr 2022 07:10:02 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Skyline-Health-Diagnostics-SHD/Certificate-Generation-Utility-for-VMWare/m-p/2902442#M332</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-04-05T07:10:02Z</dc:date>
    </item>
    <item>
      <title>Join hosts to AD using LDAPS</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Join-hosts-to-AD-using-LDAPS/m-p/2902283#M280997</link>
      <description>&lt;P&gt;Is it possible to join hosts (ESXi v7.0.3) to AD using LDAPS (rather than just LDAP)? I can't see an obvious way to do it, there's no way I can see to add a cert and no option to select LDAPS vs LDAP (and the default definitely just sends LDAP requests for the bind).&lt;/P&gt;&lt;P&gt;I already have vCenter joined to AD using LDAPS and that works fine but I wanted to join the hosts as well (although I'm aware there's some debate as to whether this is actually a good idea from a security perspective).&lt;/P&gt;&lt;P&gt;I can see there's an option to use the vSphere Authentication Proxy but I've not configured that before, would that be away to ensure LDAPS is used? Although I'd also prefer this not to be dependent on the vCenter being available so even if using the vSphere Authentication Proxy would be a way to get it working I'm not sure I'd want to go down that route.&lt;/P&gt;&lt;P&gt;I have successfully tested connecting some of the hosts using LDAP but at some point our intention is to block LDAP requests to our domain controllers.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 04 Apr 2022 13:16:24 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Join-hosts-to-AD-using-LDAPS/m-p/2902283#M280997</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-04-04T13:16:24Z</dc:date>
    </item>
    <item>
      <title>Deployments from vRSLCM fail due to vCenter permissions</title>
      <link>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Deployments-from-vRSLCM-fail-due-to-vCenter-permissions/m-p/2901299#M241</link>
      <description>&lt;P&gt;We have vRSLCM v8.6.2.0 deployed (as part of a VCF v4.4 deployment) but although the vRSLCM to vCenter role was created automatically and appears to have all the required permissions when we do a vRealize product deployment it fails during the OVF deployment stage (this happened for Workspace ONE Access, vRLI, vROPS and vRNI). Changing the integration user's global permission from the automatically created role group "&lt;SPAN&gt;vRealize Suite Lifecycle Manager to vSphere Integration" to "Administrator" allows it to work but we don't want to leave that in place permanently. &lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;We could just change it to Administrator just for deployments and change it back straight after but I'd rather fix the underlying issue (especially if other things we haven't noticed aren't working correctly either due to missing permissions). I did add some extra permissions to the&amp;nbsp;"vRealize Suite Lifecycle Manager to vSphere Integration" role (after I googled some lab deployments), that didn't help though (and all the permissions in KB&amp;nbsp;2105932 are there.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 30 Mar 2022 10:30:12 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Aria-Suite-Lifecycle/Deployments-from-vRSLCM-fail-due-to-vCenter-permissions/m-p/2901299#M241</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-03-30T10:30:12Z</dc:date>
    </item>
    <item>
      <title>Re: Upgrade VCF bundle query</title>
      <link>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Upgrade-VCF-bundle-query/m-p/2901085#M1057</link>
      <description>&lt;P&gt;I can't view the attachments but have you updated the catalogue and run the lcmbundle marker file task before downloading updates? Although it shouldn't be showing the NSX-T update as available if it requires other updates first&lt;/P&gt;</description>
      <pubDate>Tue, 29 Mar 2022 11:15:54 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Cloud-Foundation/Upgrade-VCF-bundle-query/m-p/2901085#M1057</guid>
      <dc:creator>NFerrar</dc:creator>
      <dc:date>2022-03-29T11:15:54Z</dc:date>
    </item>
  </channel>
</rss>

