One point of confusion about both the Data ONTAP PowerShell toolkit and OCPM is the way they handle cached credentials. This is further complicated by the fact that they handle this operation in similar, but slightly different ways.
When you use the Data ONTAP PS Toolkit, you normally use the Add-NaCredential cmdlet to create cached credentials. This saves the time and bother of specifying your credentials each time you do aConnect-NaController cmdlet. This works great if all you use is the PS Toolkit. You can see the default behavior if you use the Get-NaCredential cmdlet. If you look closely at the output, you will see a “HostUser” field that is populated by username that you were running under when you ran the Add-NaCredential.
It looks like this:
If you are only using the Data ONTAP PowerShell toolkit, then everything works fine.
If you are planning to use both the Data ONTAP PowerShell Toolkit and OCPM on the same system (which I really hope you are), then you will need to change things up a bit. The issue is that OCPM does not support per-user credentials. This is because this is a system level process that needs to access the NetApp controllers even when no user is logged in. This implies a SYSTEM level scope. If you use the OCPM cmdlet Add-OCStorageSystem, then the correct SYSTEM level credential is created automatically. However, if you use the Data ONTAP PS toolkit you will get user level credentials by default. Luckily, the Data ONTAP PS toolkit supports both types. You can change the default behavior by using the –SystemScope parameter. If you use that optional parameter, it creates credentials that both systems can use:
When you are all said and done, you can use both sets of PowerShell cmdlets with a single set of credentials. Like this: