POST
|
Are all the nodes same version of Windows? I found this, might be worth trying: https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-troubleshooting?redirectedfrom=MSDN#access-denied I also just realized that when -UseSSL argument is passed in, the module passes in the -Credential to the Start-DscConfiguration using New-CimSession, whereas without -UseSSL argument New-CimSession is not used. For example: https://github.com/Esri/arcgis-powershell-dsc/blob/4e1ea910cf3c237c378dfcfc1130a296de3c4bcb/Modules/ArcGIS/ArcGIS.psm1#L245-L254 Perhaps I was mistaken and -UseSSL is required so that it uses New-CimSession. Thanks, Cameron K.
... View more
06-14-2024
09:46 AM
|
2
|
1
|
498
|
POST
|
Hi @AlexBakhtin I do not believe -UseSSL argument is required so as long as WinRM HTTP is properly configured on orchestrating node and all target nodes. Thanks, Cameron K.
... View more
06-12-2024
08:45 AM
|
0
|
4
|
521
|
POST
|
Hi @julian_svcs, Yes, it is possible to deploy a base enterprise with the web server in the DMZ, however, it does require some additional environment configuration. - Trusted Hosts will need to be configured properly for all target nodes to establish trust (either the ip of each node and/or hostname.) - A common Administrator account will need to be used for the Invoke-ArcGISConfiguration -Credential flag. Since the web server node isn't on the domain, a domain administrator account cannot be used. It will need to be a local administrator account. This local administrator account will need exist on all target nodes and have the same username and password. Note: If you get an access denied error check that the LocalAccountTokenFilterPolicy is configured. Here are some helpful resources: https://stackoverflow.com/questions/40248408/powershell-remoting-to-a-workgroup-computer https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting?view=powershell-7.4 https://github.com/Esri/arcgis-powershell-dsc/wiki/Configure-the-ArcGIS-Module-to-use-WinRM-HTTPS Here are a couple commands that can be used to test the connection between the dmz node and domain joined nodes: WinRM HTTPS: Test-WSMan -ComputerName TargetNodeMachineNameOrIP -Authentication default -Port 5986 -UseSSL -Credential LocalAdministratorUsername WinRM HTTP: New-CimSession -Port 5985 -ComputerNameTargetNodeMachineNameOrIP -Authentication default -Credential LocalAdministratorUsername Test-WSMan -ComputerName TargetNodeMachineNameOrIP -Authentication default -Port 5985 -Credential LocalAdministratorUsername Thanks, Cameron K.
... View more
03-19-2024
08:39 AM
|
1
|
7
|
786
|
POST
|
Thanks @dimesv @JoseSousa @JoseSousa1, this is a good find and great feedback! In the next release of the Helm Charts (v1.3.0 for 11.3) we will improve this logic so that the second check on the admin url will wait to proceed until it's available.
... View more
03-13-2024
08:52 AM
|
2
|
0
|
799
|
POST
|
Hi @julian_svcs, We have added the ability to pass in individual single use pro license files per node starting in v4.2.0. https://github.com/Esri/arcgis-powershell-dsc/releases/tag/v4.2.0 Here is an example: https://github.com/Esri/arcgis-powershell-dsc/blob/3d056fe815c68e9676789afe9d4ca71c05cefc8d/SampleConfigs/v4/v4.2.0/DesktopPro/Pro-SingleUse.json#L1-L10
... View more
11-16-2023
01:01 PM
|
1
|
0
|
949
|
POST
|
Hi @julian_svcs, The current solution (albeit not the most ideal), is to ensure each license file resides on every target node in the same local path with the same file name (but each file will have a different license inside of it). Then this path and file name is what you would define in your json configuration file (ConfigData.Pro.LicenseFilePath). A more ideal solution though would be to have the ability to define the license file in the AllNodes section of the json configuration file so that a different license file path/file name can be defined for each target node. This is perhaps something we can aim to tackle in a future release of the module. Thanks, Cameron K.
... View more
08-30-2023
09:29 AM
|
0
|
2
|
1115
|
POST
|
Hi @julian_svcs, The ArcGIS module has some soft checks in place for checking if ArcGIS Server is already authorized or not, if already authorized then authorization is skipped. When the ForceLicenseUpdate is true, these checks are ignored and authorization is performed. This is useful for when needing to replace an expiring/expired ArcGIS Server license. However, we have not found a reliable method to check if ArcGIS Pro/ArcGIS Desktop is already authorized or not which is why the authorization is ran each time -Mode InstallLicense is invoked. Thanks, Cameron K.
... View more
06-22-2023
11:15 AM
|
1
|
4
|
1216
|
POST
|
Hi @julian_svcs, If we use the Uninstall, does this de-authorize Pro? -Mode Uninstall does not de-authorize licenses for ArcGIS Pro, or ArcGIS Desktop. Is there any option to make use of the offline respc file to license Pro using InstallLicense? If you already have a .respc file you should be able to specify it in your json configuration file using the "LicenseFilePath" attribute. Will there be any future option to use License only as a separate command? No there are no future plans for a standalone License mode. Thanks, Cameron K.
... View more
06-22-2023
10:21 AM
|
1
|
6
|
1222
|
POST
|
Hi @julian_svcs, That is quite possible. Each time -Mode InstallLicense is run, the ArcGIS Module authorizes the license silently using the C:\Program Files\ArcGIS\Pro\bin\SoftwareAuthorizationPro.exe tool. If Pro is already authorized, I suggest using -Mode Install to apply the patch rather than -Mode InstallLicense. Thanks, Cameron K.
... View more
06-20-2023
02:14 PM
|
0
|
8
|
1234
|
POST
|
Hello Eric, This is a great question and a valid use case! Unfortunately though, the PowerShell DSC ArcGIS module doesn't have the ability to change the location or prevent the local upgrade-backup from occurring. Thanks, Cameron K.
... View more
09-17-2020
03:36 PM
|
1
|
2
|
727
|
POST
|
Which version of portal are you using? Are you trying to just change the content directory path (C:\arcgisportal\content to say something like D:\arcgisportal\content, D:\arcgisportal\db, D:\arcgisportal\index, etc)? These can be updated using the portaladmin api: Changing the portal content directory—ArcGIS Enterprise | Documentation for ArcGIS Enterprise Or are you trying to change the actual installation directory (C:\Program Files\ArcGIS\Portal to say something like D:\Program Files\ArcGIS\Portal)? I recommend against it because I had posted that workflow 5 years ago and it would need to be retested against newer versions. Also, if I recall correctly everything had to remain the same, including the content/install directory paths.
... View more
08-28-2020
09:37 AM
|
1
|
1
|
2003
|
POST
|
Hello Carlos, I would actually recommend against this workflow now. Since this post there have the two blogs published with two different methods outlined. 1. Migrate to a new machine in ArcGIS Enterprise 2. Migrate to a new machine in ArcGIS Enterprise using the WebGIS DR tool Thanks, Cameron K.
... View more
08-28-2020
09:05 AM
|
0
|
3
|
2003
|
POST
|
Hello Jeff, Apologies for the delayed response and thank you for sharing those details. The existing environments can still be upgraded using Chef Infra Client. Essentially all that Chef Server is really doing is running Chef Infra client on each bootstrapped node, copying over the cookbooks and json file. Then Chef Infra Client Infra Client is doing all the work. So technically, you could still remote into each node, install Chef Infra Client, download the cookbooks, and modify the existing json file to perform the upgrades. I would suggest this route rather than migrating to PowerShell DSC to perform the upgrade since this wouldn't be very straight forward and presents allot of risks. Not only are the attributes/parameters not 1 to 1 but also the resources/recipes vary. For example, Portal Settings may get changed. Here is the resources that the Portal Upgrade would use: arcgis-powershell-dsc/PortalUpgradeV2.ps1 at 7d365cb94b9ae351797af2cce582dd8b811f1a49 · Esri/arcgis-powershell-dsc · Git… Along with the json attributes, you would also need to examine the Chef recipes used in the original deployment and compare them with the DSC resources to see what differences there are and assess if any settings/configuration would get changed during the upgrade. If you do decide to go this route I suggest performing allot of testing prior to implementing it in production and have adequate backups/images to restore to if things don't go as planned. Regards, Cameron K.
... View more
03-05-2020
12:33 PM
|
0
|
0
|
1301
|
POST
|
Hello Jeff, This is a very intriguing idea, but presents many challenges. One challenge is the json file attributes are different between Chef and Powershell dsc. Typically with upgrades in PowerShell we take the original json file and update it with "OldVersion" parameter as well as update the paths to the new license files and setups. However, in this case the json file would need to be built from scratch and essentially needs to have matching values. Another hurdle is that in Chef we create an Administrator username/password for the ArcGIS Server Site, and a separate account for Portal. However, in PowerShell DSC we only allow one account to be specified so this means both Portal and Server will have the same username/password. This would present a problem when registering the web adaptors since a token needs to be passed. But perhaps this could be worked around by manually updating both ArcGIS Server and Portal accounts to have the same username/password. Or possibly having separate json files for each product to be upgraded. There could be other "gotcha's" and caveats as well since under the hood of Chef and PowerShell are very different. There would need to be allot of testing done prior to recommending this as an option. I know Chef recently updated their Enterprise licensing agreement. My understanding is now they charge for redistributing at an Enterprise Level but the use of the Chef Infra Client I believe is still free at least for testing purposes. Perhaps you could expand on the why there will be significant costs for your current solution? Best regards, Cameron K.
... View more
02-28-2020
12:59 PM
|
0
|
2
|
1301
|
POST
|
Just to confirm the recommended/supported workflow for applying patches after an upgrade, is to re-run the PowerShell module with -mode install. This is so that the upgrade can be verified and a backup/snapshot can be made prior to applying patches.
... View more
02-11-2020
02:19 PM
|
0
|
1
|
927
|
Title | Kudos | Posted |
---|---|---|
2 | 06-14-2024 09:46 AM | |
1 | 03-19-2024 08:39 AM | |
2 | 03-13-2024 08:52 AM | |
1 | 11-16-2023 01:01 PM | |
1 | 06-22-2023 11:15 AM |
Online Status |
Offline
|
Date Last Visited |
06-14-2024
06:10 PM
|