Yes, this connection has been achieved, but the returned documents point to a few specific requirements in your code and in Microsoft 365 configuration:

1. If you are using an OAuth access token, do not send the password together with it. The guidance in the retrieved discussion is explicit: when using an access token, the password should not also be sent. [1][2]

2. For your call syntax, the example correction shown is:

Set status=server.Connect(servername,user,,AccessToken)

and not:

Set status=server.Connect(servername,user,AccessToken)

The empty third parameter is required so that the token is passed as the 4th argument. [1][2]

3. The token must include the proper mail scopes. The retrieved material specifically mentions using scopes such as:

• https://outlook.office.com/POP.AccessAsUser.All
• https://outlook.office.com/SMTP.Send

It also notes that adding additional scopes may prevent the token from working for mail retrieval. [1][2]

4. Microsoft also requires a tenant ID in the authorization request. The example in the retrieved material uses common for outlook.com accounts, but for your domain you may need to use your tenant ID instead of common. [1][2]

5. One report in the retrieved documents says that the %Net.POP3 implementation follows Microsoft’s OAuth POP approach, and that once you can correctly acquire and pass the access token, it should work. [3][4]

6. Another important point is that POP access in Office 365 must be enabled, because one of the retrieved reports states that POP access is disabled by default on the Outlook 365 side. [3][4]

So, based on the retrieved material, the main correction to test in your case is this call:

Set status=server.Connect(servername,user,,AccessToken)

and make sure:

• you are not sending the password with the token,
• the token was requested with the POP scope,
• the tenant ID is correct,
• POP is enabled in Office 365. [1][2][3][4]

Your -ERR Authentication failure: unknown user name or bad password can therefore be caused by sending password + token together, using the wrong Connect() argument position, using an unsuitable scope set, or not having POP enabled on the Microsoft side. [1][2][3][4]

Sources:

Pelo material disponível, não há um mecanismo documentado para obter somente os nomes dos índices corrompidos de forma segura em memória, sem que o %ValidateIndices() acumule erros em nível de linha no array .errors. A documentação citada descreve como validar índices e como reconstruí-los, mas não apresenta uma saída “apenas nomes dos índices” para o cenário que você descreveu. [1]

O que o material confirma é:

• Você pode validar índices com $SYSTEM.OBJ.ValidateIndices() ou %Library.Storage.%ValidateIndices(). Ambos verificam a integridade dos índices e podem validar todos os índices da tabela ou uma %List específica de nomes de índices. [1]
• Se o objetivo final for reconstruir índices já conhecidos como corrompidos, o método preferido é %BuildIndices(), porque %ValidateIndices() é significativamente mais lento. [1]
• %BuildIndices() aceita uma lista de nomes de índices, por exemplo: SET status = ##class(myschema.mytable).%BuildIndices($ListBuild("NameIDX","SpouseIDX")). [1]
• Se você quiser que a validação inclua também tabelas-filhas de coleções, o material informa que $SYSTEM.OBJ.ValidateIndices() pode fazer isso; %Library.Storage.%ValidateIndices() exige chamadas separadas para índices dessas tabelas-filhas. [1]

Então, com base apenas nas fontes encontradas, a resposta é que não há, na documentação retornada, uma forma documentada e memory-safe de pedir ao %ValidateIndices() apenas os nomes dos índices corrompidos. Se você já souber quais índices precisam ser refeitos, pode passá-los diretamente para %BuildIndices() em uma lista. [1]

Sources: