Click HERE to see how Saviynt Intelligence is transforming the industry. |
11/07/2024 02:02 AM
Hi all,
I'm running into an issue with handling backslashes (\) in server paths within a dataset that I upload. The dataset includes paths formatted with single and double backslashes, such as \\abcd01\efg$\01\.
In the dataset preview, the path appears as \abcd01efg$01, which is expected behavior based on escaping rules.
However, when I create a new user, a new account is created in the AD Endpoint (following a technical rule), and the path data from the dataset should populate customproperty4 in the account (dynamic Attribute).
The problem is that the path format in customproperty4 is not what I expect; for instance, instead of \\abcd01\efg$\01\, it shows up as \\abcd01efg$04, which differs from both the dataset and the preview.
Additionally, if I request a new account via ARS, the escaping behaves differently. By using \\\\abcd01\\efg$\\11\\, I manage to get the expected output, \\abcd01\efg$\01\, but only for the ARS request,
when account created via technical rule the result looks like \\\\abcd01\\efg$\\04\\.
I've tried various formats in the dataset, adjusting the count of backslashes, like \\abcd01\\efg$\\11\\ or \\\abcd01\\efg$\\11\\, and so forth.
No matter which variation I use, I can't achieve a stable double backslash at the start and single backslashes in between across all contexts.
My goal is to have \\abcd01\efg$\01\ correctly written into the account’s customproperty4 field via the dynamic attribute, with the account itself being created through the technical rule.
I’ve included a table that shows the different versions I tried in the dataset and the resulting values in the account field and dataset preview.
If the technical rule or dynamic attribute plays a role, I’d be happy to provide further details on those as well.
Any insights or suggestions for achieving consistent escaping behavior in the account field would be greatly appreciated. Thanks!