Creating existing item then failing

[blighter]

I'm using Sync-ADUsers.ps1 without any changes outside of the 'configuration' options, and am seeing strange behaviour. The script seems to find a department or company but then goes on to try and create it anyway, obviously failing

.\Sync-ADUsers.ps1 -EmailDeletedUsersReport Transcript started, output file is .\Logs\snipeit-ad-sync_2023-11-16.log VERBOSE: [2023/11/16 11:55:21] Connecting to Snipe-It instance at [] VERBOSE: [Get-SnipeItEntityAll] Collecting all existing [users] from Snipe-It... VERBOSE: [Get-SnipeItEntityAll] Got back 315 results for [users] VERBOSE: [Get-SnipeItEntityAll] Collecting all existing [companies] from Snipe-It... VERBOSE: [Get-SnipeItEntityAll] Got back 4 results for [companies] VERBOSE: [Get-SnipeItEntityAll] Collecting all existing [departments] from Snipe-It... VERBOSE: [Get-SnipeItEntityAll] Got back 54 results for [departments] VERBOSE: [Get-ADUsersByGroup] Collecting all users from AD group [] (Nested=True, With FilterMap=False)... VERBOSE: [Get-ADUsersByGroup] Getting properties for 215 users... VERBOSE: [Get-ADUsersByGroup] Total filtered AD users collected: 215 VERBOSE: [Get-ADUsersByGroup] Collecting all users from AD group [] (Nested=True, With FilterMap=False)... VERBOSE: [Get-ADUsersByGroup] Getting properties for 63 users... VERBOSE: [Get-ADUsersByGroup] Total filtered AD users collected: 63 [2023/11/16 11:55:53] Formatting users... [2023/11/16 11:55:55] Starting sync... VERBOSE: [Sync-SnipeItUser] Processing user [] with employee_num [] Write-Error: \Documents\PowerShell\Modules\SnipeitPS\1.10.227\Public\New-SnipeitCompany.ps1:68:23 Line | 68 | $result = Invoke-SnipeitMethod @Parameters | ~~~~~~~~ | name ---- {The name has already been taken.}
Sync-SnipeItUser: \Sync-ADUsers.ps1:428:24 Line | 428 | … $sp_user = Sync-SnipeItUser -User $user -Verbose @extraParams | ~~~~~~~~~~ | [Get-SnipeItEntityByName] Fatal ERROR creating new snipeit companies with name []! Returned entity has invalid ID Sync-SnipeItUser: \Sync-ADUsers.ps1:428:24 Line | 428 | … $sp_user = Sync-SnipeItUser -User $user -Verbose @extraParams | ~~~~~~~~~~ | [Get-SnipeItEntityByName] Fatal ERROR creating new snipeit departments with name []! Returned entity has invalid ID

I tried to use the functions to mimic the behaviour and have been successful:

Get-SnipeItDepartment | ?{$_.Name -eq "IT"}

id : 88 name : IT phone : fax : image : company : manager : location : users_count : 0 created_at : @{datetime=2023-11-16 12:17:57; formatted=2023-11-16 12:17 PM} updated_at : @{datetime=2023-11-16 12:17:57; formatted=2023-11-16 12:17 PM} available_actions : @{update=True; delete=True}

Get-SnipeItDepartmentByName -Name "IT" OperationStopped: ...\Snipeit-Sync-PS.ps1:1030:21 Line | 1030 | … Throw [System.Net.WebException] ("[Get-SnipeItEntityByNam … | ~~~~~~~~~~~~~ | [Get-SnipeItEntityByName] Fatal ERROR creating new snipeit departments with name [IT]! Returned entity has invalid ID

[mattcarras]

Hi @blighter,

It sounds like there may be some sort of problem with the cache. Do you get the same error if you give the -NoCache parameter?

If you haven't already, I'd also try setting $DebugPreference = 'Continue' and try calling the function again. That'll let you see exactly what is being passed to SnipeItPS.

[late-chapter-lived]

@mattcarras I would guess that @blighter is using PSCore PS Core deserializes numbers in JSON as int64 rather than int32 like PS5. (See https://github.com/PowerShell/PowerShell/issues/14264)

Unfortunately, this breaks your checks that returned entity id numbers are valid.

if ([string]::IsNullOrWhitespace($sp_entity.StatusCode) -And $sp_entity.id -is [int]) {
    Write-Verbose ("[Get-SnipeItEntityByName] Created new type of [{0}] in snipe-it with name [{1}] and id [{2}]" -f $EntityType,$sp_entity.name,$sp_entity.id)
    $update_cache = $true
}

I had to update your checks for [int] to [int64]. I suspect that would then break things in the opposite direction and I don't have a good testing setup for 5.0, so I haven't submitted a pull.

edit: Nothing like walking away to see the obvious. The check could verify either.