Cybersecurity
DevOps Cloud
IT Operations Cloud
Good morning,
This is command that they used, (with names blocked out of course)
Hi Daniel
To move a resource:
curl -k --user admin:novell -H "Content-Type:application/json" -X POST 192.168.90.10:9710/.../moverequests --data '{"sources":[{"id":"RESOURCE.dom1.po1.testmove","resourceOwnerId":"USER.dom2.po2.user1"}],"postOfficeId":"POST_OFFICE.dom2.po2"}'
admin = GW Admin User
novell = password
change IP to that of the correct server
"testmove" is the name of the resource being moved.
ResourceOwnerID is the NEW resource owner
postOfficeID is the post office the resource is being moved to.
Cheers,
Good morning
So in your example "testmove" can be replaced by Cxx/Rexxxls~ as long as it's inside the "" (Double Quotes)
192.168.90.10 would be replaced by 10.xx.xx.xx
Thank you,
Daniel
Good morning
This is from the customer
Not sure I am following what this is. Is this a command that should allow us to move the resource without worrying about the association?
Basically when we tried to move the object previously, it was encountering an error with a Sync Error. So to the question above would this take into account any Associations?
Thank you,
Daniel
Good morning
This is from the customer
Not sure I am following what this is. Is this a command that should allow us to move the resource without worrying about the association?
Basically when we tried to move the object previously, it was encountering an error with a Sync Error. So to the question above would this take into account any Associations?
Thank you,
Daniel
Hi,
A resource should not have any association. It does not have an LDAP counterpart.
Cheers,
Good morning,
That is part of the issue, the Resource in Question was created in an earlier version of GroupWise (prior to GW 2012) back-line provided us/customer with a script that was supposed to sever that association so that the Resource could then be moved.
The customer is/was attempting to run the script on that Resource, and that's when they are receiving the error, which again seems to be because the Resource has a "/" in it's name. Another Engineer suggested doing the following: "Cxx/Rexxxls" or "Cxx\/Rexxxls" so the command would look something like this, https://10.xx.xx.xx:9710/gwadmin-service/domains/BxxMxxO/postoffices/PO1/users/Cxx/Rexxxls~/directorylink
The customer is going to be trying again today
Thank you,
Daniel
Hi Daniel,
If that doesn't work you could consider renaming the resource first to remove the illegal characters:
curl -k --user admin:password -H "Content-Type:application/json" -X POST ipofserver:9710/.../rename --data '{"objectId":"RESOURCE.dom1.po1.Test Resource","newObjectId":"TestResource"}'
In the example above the resource had a space in the name. This should work with any other illegal character.
Cheers,