Apparently, If you try and set “whocaninvite” in groups settings via API to “NONE_CAN_INVITE”, the API returns the value as “ALL_MANAGERS_CAN_INVITE”.
If you set other settings say “ALL_MANAGERS_CAN_INVITE” or “ALL_MEMBERS_CAN_INVITE” it works fine and confirms by returning the same value back.
This is the same if you do via GAM tool or via their web portal to change a group settings
Above, if you select “Managers of the group” and save.. and then go back to the group, you will see the tick gone.
Apparently not affecting everyone.. Well it was and then they said they fixed it, and I said.. Nope.. So they have to open a new bug 72470856 for this one.
C’mon google.. you guys are the coders right? the developers?
Another day – another bug #bugmaster (although a very small one)
If you use Azure AD Connect and manually upgrading to v1.1.649.0 and have a Generic LDAP MA in your configuration, after the upgrade you will get a “no-start-ma” error on Delta / Full Import or an “extension-dll-exception” on an export or when syncs start automatically after the upgrade.
Fix: Easy one – open the MA and click through each config page to refresh the MA manually.
Microsoft has acknowledged the bug and will fix it in the next release.
I am surprised as there aren’t that many MA extensions in AADConnect so how this was missed in their internal testing..
We use Google API to provision and manage users in GoogleApps via Google MA FIM/MIM.
I have recently found that when you make changes to a user’s orgUnitPath and send it as a patch / update to Google, the API does not confirm it by returning the value in the return. But the change is actually made and if you do a GET for the user you can see the modified orgUnitPath
It fails to do the same with Google API Explorer and OAUTH Playground
Request
Google orgUnitPath PUT
1
2
3
4
PUT https://www.googleapis.com/admin/directory/v1/users/EMAILADDRESS?key={YOUR_API_KEY}
{
"orgUnitPath":"/AdditionalServices"
}
Response (no orgUnitPath is returned although change has been made)
Google API Return
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
200OK
-Showheaders-
{
"kind":"admin#directory#user",
"id":"103043262939656712601",
"etag":"\"XXXXXXXXXXXXX\"",
"primaryEmail":"XXXXXXXXX",
"name":{
"givenName":"XXXXX",
"familyName":"XXXXXXX",
"fullName":"XXXXXXXXXXXX"
},
"isAdmin":true,
"isDelegatedAdmin":false,
"lastLoginTime":"2017-09-11T02:33:46.000Z",
"creationTime":"2015-06-08T03:37:37.000Z",
"agreedToTerms":true,
"suspended":false,
"changePasswordAtNextLogin":false,
"ipWhitelisted":false,
"emails":[
{
"address":"XXXXXXXXXXXXXX",
"primary":true
},
{
"address":"XXXXXXXXXXXXXX"
}
],
"addresses":[
{
"type":"custom",
"customType":"",
"streetAddress":""
}
],
"organizations":[
{
"name":"",
"customType":""
},
{
"primary":true,
"type":"work",
"customType":"",
"department":"",
"location":""
}
],
"phones":[
{
"value":"",
"type":"custom",
"customType":""
}
],
"nonEditableAliases":[
""
],
"customerId":"XXXXXXXX",
"isMailboxSetup":true,
"includeInGlobalAddressList":false
}
Google has confirmed this as a high priority bug (b/65534998) but its been a week since reported.. Their current workaround suggested is to use GET after doing a PUT or a PATCH and not rely on the current return values of them. Doesn’t really solve the issue for us in an extremely large environment and also means changing the code etc..
