Google Apps for CAP Webinar

[A.Member]

Finally had a chance to look at your account creation script closer and think I understand your approach but want to confirm:

You're setting up the accounts with CAP ID but then creating an alias so the members have an email address like firstname.lastname@tncap.us, correct?  If this is correct, do the member login to their account with the alias or do they need to login with the capid@tncap.us?  I'm still very much learning Google Apps (so pardon me if this seems basic) but my understanding is a user must login with credentials used to create the account (ie, in this case the members CAP ID).

Correct.  Account names are in the form of <capid>@tncap.us  Users log in with that as their account name.

This provided two main advantages:
1.  Uniqueness.  I don't need to check for uniqueness in names.  No matter how many John Smiths I have, each and every one has a unique CAPID, saving me a lot of code checking for uniqueness, and coding rules to fix duplicates.

2.  Delineation of script-managed accounts:  Never put all your eggs in one basket.  A bad CAPWATCH file could have your script disable every single account in your system (including yours as the admin).  For that reason, we have a small number of manually administered accounts.  The rule is, if the account name starts with a number, then the script will manage it.  Otherwise, it will leave it alone.  So, while my 477407@tncap.us account is managed by the script, I have a back-door account that will let me in if things go wrong.  I need to redo it since we rewrote some of our provisioning, but there was a site where the password for that account could be reset by anyone who is assigned as a Wing ITO, Commander or Vice Commander for emergency purposes, so if I get disgruntled, my access can be taken away!

Another reason for a manually-administered account is someone outside your scope needs access.  For example, if I want to let someone from SER into our system, I can create an account for them based on their name.  So long as I don't start it with a number, it will not be auto-disabled, and you can closely monitor access by that account to make sure people aren't abusing the account.

Finally, it's a good idea to have an emergency account, and record that in your Internet Operations application in eServices.

I like it.  We're tracking in the same direction.

On the topic of CAPWATCH, can you shed a little light on the impact of a bad CAPWATCH update.  In your script it looks like you check for the last CAPWATCH download date.  If a new download is not received, the last download date should be the same and no action is taken (ie the script is not run).  However, what happens if CAPWATCH is updated but they have an issue populating a table, resulting in say blank columns in the Member table (I don't have experience loading CAPWATCH daily so I don't know how real that problem could be)?  I don't see anything obvious that looks for such a scenario.  So, based on what I think I understand, that will result in the Google account being disabled, correct?  Is the fix simply to wait for a good CAPWATCH file (possibly the next day) when the script reruns again and switches the account status from disable to active?  It doesn't recreate brand new accounts, correct?

[JeffDG]

Finally had a chance to look at your account creation script closer and think I understand your approach but want to confirm:

You're setting up the accounts with CAP ID but then creating an alias so the members have an email address like firstname.lastname@tncap.us, correct?  If this is correct, do the member login to their account with the alias or do they need to login with the capid@tncap.us?  I'm still very much learning Google Apps (so pardon me if this seems basic) but my understanding is a user must login with credentials used to create the account (ie, in this case the members CAP ID).

Correct.  Account names are in the form of <capid>@tncap.us  Users log in with that as their account name.

This provided two main advantages:
1.  Uniqueness.  I don't need to check for uniqueness in names.  No matter how many John Smiths I have, each and every one has a unique CAPID, saving me a lot of code checking for uniqueness, and coding rules to fix duplicates.

2.  Delineation of script-managed accounts:  Never put all your eggs in one basket.  A bad CAPWATCH file could have your script disable every single account in your system (including yours as the admin).  For that reason, we have a small number of manually administered accounts.  The rule is, if the account name starts with a number, then the script will manage it.  Otherwise, it will leave it alone.  So, while my 477407@tncap.us account is managed by the script, I have a back-door account that will let me in if things go wrong.  I need to redo it since we rewrote some of our provisioning, but there was a site where the password for that account could be reset by anyone who is assigned as a Wing ITO, Commander or Vice Commander for emergency purposes, so if I get disgruntled, my access can be taken away!

Another reason for a manually-administered account is someone outside your scope needs access.  For example, if I want to let someone from SER into our system, I can create an account for them based on their name.  So long as I don't start it with a number, it will not be auto-disabled, and you can closely monitor access by that account to make sure people aren't abusing the account.

Finally, it's a good idea to have an emergency account, and record that in your Internet Operations application in eServices.

I like it.  We're tracking in the same direction.

On the topic of CAPWATCH, can you shed a little light on the impact of a bad CAPWATCH update.  In your script it looks like you check for the last CAPWATCH download date.  If a new download is not received, the last download date should be the same and no action is taken (ie the script is not run).  However, what happens if CAPWATCH is updated but they have an issue populating a table, resulting in say blank columns in the Member table (I don't have experience loading CAPWATCH daily so I don't know how real that problem could be).  I don't see anything obvious that looks for such a scenario.  So, based on what I think I understand, that will result in the Google account being disabled, correct?  Is the fix simply to wait for a good CAPWATCH file (possibly the next day) when the script reruns again and switches the account status from disable to active?  It doesn't recreate brand new accounts, correct?

What I worry about is a hiccup at NHQ results in a CAPWATCH that has a DownLoadDate that's new, but the Member table is empty.

That would result in every account we have that's script-managed being "disabled" en masse.  If we didn't have other accounts, we could not get in to fix it easily.

Hasn't happened yet, but I do contingency plans for as many failure modes as I can conceive of.

[A.Member]

Finally had a chance to look at your account creation script closer and think I understand your approach but want to confirm:

You're setting up the accounts with CAP ID but then creating an alias so the members have an email address like firstname.lastname@tncap.us, correct?  If this is correct, do the member login to their account with the alias or do they need to login with the capid@tncap.us?  I'm still very much learning Google Apps (so pardon me if this seems basic) but my understanding is a user must login with credentials used to create the account (ie, in this case the members CAP ID).

Correct.  Account names are in the form of <capid>@tncap.us  Users log in with that as their account name.

This provided two main advantages:
1.  Uniqueness.  I don't need to check for uniqueness in names.  No matter how many John Smiths I have, each and every one has a unique CAPID, saving me a lot of code checking for uniqueness, and coding rules to fix duplicates.

2.  Delineation of script-managed accounts:  Never put all your eggs in one basket.  A bad CAPWATCH file could have your script disable every single account in your system (including yours as the admin).  For that reason, we have a small number of manually administered accounts.  The rule is, if the account name starts with a number, then the script will manage it.  Otherwise, it will leave it alone.  So, while my 477407@tncap.us account is managed by the script, I have a back-door account that will let me in if things go wrong.  I need to redo it since we rewrote some of our provisioning, but there was a site where the password for that account could be reset by anyone who is assigned as a Wing ITO, Commander or Vice Commander for emergency purposes, so if I get disgruntled, my access can be taken away!

Another reason for a manually-administered account is someone outside your scope needs access.  For example, if I want to let someone from SER into our system, I can create an account for them based on their name.  So long as I don't start it with a number, it will not be auto-disabled, and you can closely monitor access by that account to make sure people aren't abusing the account.

Finally, it's a good idea to have an emergency account, and record that in your Internet Operations application in eServices.

I like it.  We're tracking in the same direction.

On the topic of CAPWATCH, can you shed a little light on the impact of a bad CAPWATCH update.  In your script it looks like you check for the last CAPWATCH download date.  If a new download is not received, the last download date should be the same and no action is taken (ie the script is not run).  However, what happens if CAPWATCH is updated but they have an issue populating a table, resulting in say blank columns in the Member table (I don't have experience loading CAPWATCH daily so I don't know how real that problem could be).  I don't see anything obvious that looks for such a scenario.  So, based on what I think I understand, that will result in the Google account being disabled, correct?  Is the fix simply to wait for a good CAPWATCH file (possibly the next day) when the script reruns again and switches the account status from disable to active?  It doesn't recreate brand new accounts, correct?

What I worry about is a hiccup at NHQ results in a CAPWATCH that has a DownLoadDate that's new, but the Member table is empty.

That would result in every account we have that's script-managed being "disabled" en masse.  If we didn't have other accounts, we could not get in to fix it easily.

Hasn't happened yet, but I do contingency plans for as many failure modes as I can conceive of.

Yes, that's exactly what I was referring to but perhaps didn't articulate well. 

Help me understand this better...what happens in a scenario where an active member let's their membership lapse/non-renews (CAPID goes from active to expired in CAPWATCH Member table) but then, say, 3 weeks later they update their renewal (have gone from expired back to active in CAPWATCH under the same CAP ID)?  In this scenario, what takes place with the Google Account?  How is this handled?

[JeffDG]

Finally had a chance to look at your account creation script closer and think I understand your approach but want to confirm:

You're setting up the accounts with CAP ID but then creating an alias so the members have an email address like firstname.lastname@tncap.us, correct?  If this is correct, do the member login to their account with the alias or do they need to login with the capid@tncap.us?  I'm still very much learning Google Apps (so pardon me if this seems basic) but my understanding is a user must login with credentials used to create the account (ie, in this case the members CAP ID).

Correct.  Account names are in the form of <capid>@tncap.us  Users log in with that as their account name.

This provided two main advantages:
1.  Uniqueness.  I don't need to check for uniqueness in names.  No matter how many John Smiths I have, each and every one has a unique CAPID, saving me a lot of code checking for uniqueness, and coding rules to fix duplicates.

2.  Delineation of script-managed accounts:  Never put all your eggs in one basket.  A bad CAPWATCH file could have your script disable every single account in your system (including yours as the admin).  For that reason, we have a small number of manually administered accounts.  The rule is, if the account name starts with a number, then the script will manage it.  Otherwise, it will leave it alone.  So, while my 477407@tncap.us account is managed by the script, I have a back-door account that will let me in if things go wrong.  I need to redo it since we rewrote some of our provisioning, but there was a site where the password for that account could be reset by anyone who is assigned as a Wing ITO, Commander or Vice Commander for emergency purposes, so if I get disgruntled, my access can be taken away!

Another reason for a manually-administered account is someone outside your scope needs access.  For example, if I want to let someone from SER into our system, I can create an account for them based on their name.  So long as I don't start it with a number, it will not be auto-disabled, and you can closely monitor access by that account to make sure people aren't abusing the account.

Finally, it's a good idea to have an emergency account, and record that in your Internet Operations application in eServices.

I like it.  We're tracking in the same direction.

On the topic of CAPWATCH, can you shed a little light on the impact of a bad CAPWATCH update.  In your script it looks like you check for the last CAPWATCH download date.  If a new download is not received, the last download date should be the same and no action is taken (ie the script is not run).  However, what happens if CAPWATCH is updated but they have an issue populating a table, resulting in say blank columns in the Member table (I don't have experience loading CAPWATCH daily so I don't know how real that problem could be).  I don't see anything obvious that looks for such a scenario.  So, based on what I think I understand, that will result in the Google account being disabled, correct?  Is the fix simply to wait for a good CAPWATCH file (possibly the next day) when the script reruns again and switches the account status from disable to active?  It doesn't recreate brand new accounts, correct?

What I worry about is a hiccup at NHQ results in a CAPWATCH that has a DownLoadDate that's new, but the Member table is empty.

That would result in every account we have that's script-managed being "disabled" en masse.  If we didn't have other accounts, we could not get in to fix it easily.

Hasn't happened yet, but I do contingency plans for as many failure modes as I can conceive of.

Yes, that's exactly what I was referring to but perhaps didn't articulate well. 

Help me understand this better...what happens in a scenario where an active member let's their membership lapse/non-renews (CAPID goes from active to expired in CAPWATCH Member table) but then, say, 3 weeks later they update their renewal (have gone from expired back to active in CAPWATCH under the same CAP ID)?  In this scenario, what takes place with the Google Account?  How is this handled?

OK...let's say john smith, capid 123456 expires DEC 31 and renews Jan 15

On Jan 1, the account will be suspended, and John will no longer have access to any member resources.  Then on the 16th, it will be unsuspended, and all prior privs will automatically be restored

[A.Member]

What I worry about is a hiccup at NHQ results in a CAPWATCH that has a DownLoadDate that's new, but the Member table is empty.

That would result in every account we have that's script-managed being "disabled" en masse.  If we didn't have other accounts, we could not get in to fix it easily.

Hasn't happened yet, but I do contingency plans for as many failure modes as I can conceive of.

Yes, that's exactly what I was referring to but perhaps didn't articulate well. 

Help me understand this better...what happens in a scenario where an active member let's their membership lapse/non-renews (CAPID goes from active to expired in CAPWATCH Member table) but then, say, 3 weeks later they update their renewal (have gone from expired back to active in CAPWATCH under the same CAP ID)?  In this scenario, what takes place with the Google Account?  How is this handled?

OK...let's say john smith, capid 123456 expires DEC 31 and renews Jan 15

On Jan 1, the account will be suspended, and John will no longer have access to any member resources.  Then on the 16th, it will be unsuspended, and all prior privs will automatically be restored

Makes sense and is what I understood when looking at the script. 

So, it seems a worst case scenario might be where National runs into an issue and doesn't populate Member table correctly, resulting in all numerical based accounts being moved to suspended.  However, you'll still have access to your alpha-based accounts and when National corrects the issue (say the following day), the script is rerun and should return each of those accounts back to active.  Thus, resolving the issue.

Also, in your script, it indicates that you disable Google accounts but don't actually delete them.  Is there a scenario where you actually perform maintenance (whether via script or manually) and actually delete the user account; ex. after 2 years in suspended status (because national would reissue a new CAP ID)?  We have a 2,000 account limit on Google Apps so after awhile it seems we'd need to clean some of those "old" disabled accounts.  Have you run into this scenario?