Thursday, September 28, 2017

Cisco Anyconnect VPN Failed to get configuration from secure gateway

Out of the blue, users start getting these errors.
Failed to get configuration from secure gateway. Contact your system administrator.

AnyConnect was not able to establish a connection to the specified secure gateway. Please try connecting again.
 

It turned out my certificate had expired, I found this out through another fix where you clear preferences.xml. After deleting that file and trying to connect, it pops up with the certificate and I saw it had just expired. While the certificate auto renews through GoDaddy, it doesn't on the ASA. I didn't update the certificate, we have a network guy that does that and he doesn't tell me how he does stuff.
I know he generated a CSR that I had to paste into GoDaddy. GoDaddy verified and issued the cert, and I downloaded the Apache version of the cert from GoDaddy.

Friday, September 15, 2017

something went wrong and outlook couldn’t set up your account. please try again. if the problem continues, contact your email administrator.

I got this error on a new install of Windows 10. I was also getting kb2566790 DNS errors with skype.
After going through some internet fixes (disabling IPv6, full reset of 10) to no avail, I was thinking it might just be the version of W10. A new 'nothing works' update or something.

After some trial and error, I tried adding the account under the local admin account. Worked fine. Added this specific user as a local admin and Skype no longer had the issue, and I was able to add the email account.

This particular user is part of a domain I don't manage within the same corporate umbrella. I'm guessing they have some dumb group policy or something. I didn't care to look, I just needed to get this user running.

Wednesday, September 13, 2017

Resyncing previously synced account in Office 365 and synching a new account to an existing

If you read my previous article about my migration fiasco, you'll remember I pointed out that previously synced accounts are fubar'd and won't sync.
After some discussion with Microsoft, I was informed there is a source anchor/immutable ID that populates in synced accounts. This ties the account to the local On Premise AD account and won't let anything else connect.
In my case, the old "On Premise AD" was a cloud Okta server that we didn't have anymore. Luckily, these accounts transitioned to In Cloud (I don't remember if they went into a Soft Delete, but they probably did.)
The first tech I spoke with a while back gave me some pretty... scary solutions.
Option A would be to disable Azure sync for 3 DAYS and run a bunch of powershells.
Option B would be to delete the account in question, sync an account from the local ad and reattach the mailbox via powershell. Rendering all shares to this account useless. FUUUUUUAAAA.

Well, one of the accounts was my own and I Option B'd that muthafuka. 0/10 would not recommend.

This whole time I was like, can't we just get rid of that immutable ID? clear the flag? The MS guy said the only way would be to disable the Azure Sync for 24-36 hours...

Fast forward, and I found out this is not the case.
Once the account is in In Cloud status, you just have to run a simple powershell on the account.
You will have to do this through the Azure AD module for powershell  http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185
And good luck with that. I have fully updated Windows 10 and it keeps saying I need Powershell 2.0 or higher... (if you have fixed this stupid error, please let me know, I gave up and set it up on my DC)

  • Run the command "Connect-MsolService". (Enter Global Admin credentials when prompted).
  • Check the details of a user with the below command:
  • Get-MsolUser -UserPrincipalName user@domain.com | FL
  • To remove the Immutable ID, run below command:
  • Set-MsolUser -UserPrincipalName user@domain.com -Immutableid ""
  • The above command will remove the Immutable ID for the user


At this point the account is ready to be synced with a new AD account on any local AD anywhere.

Unable to convert O365 mailbox to shared mailbox

Converting a mailbox to a shared mailbox is normally pretty easy in Office 365.
Log into the Admin center, Users, locate the user, expand Mail Settings (you will see this if the user has proper licensing and you have proper admin level) and click on the Convert to shared Mailbox option


Easy Peasy.
So you're running O365 and you're thinking 'Boy, it would be nice to have at least the same password between my local AD and Office 365.'
So you do that, pretty simple.
But wait, what's this? A user left and now you need to convert them to a shared mailbox so everyone can view their email and pretend to be them. (insert your own personal reason for making a user mailbox shared)
You follow the same steps as before, but the option isn't there.

Darn!
This is because the account is now Synced with a local active directory.
Donezo, right? I guess its time to give all the users full access rights on this mailbox... But wait, there's more!
If you move the terminated user, or whatever the reason, to a NON syncing OU, the account will soft delete.
I know DELETE is scary, but this is a soft scary. Think lion or koala, just kidding, its not that bad.
Now that the account is no longer an active user, it will show up in Deleted Users in Admin

Find the user here, and Restore the user, you can set a password or let it do a random password, doesn't really matter.
Once that is done, the account will now be "In Cloud" and you can convert it to a shared mailbox.

Getting RTL8812au passed to Virtualbox VM (Ubuntu)

There are no guarantees, I just write these notes so I can come back to them. First, get the dongle working on the host OS. After going thro...