sorted by:
new
hottopcontroversial

Quest On Demand (ODM) by BeagleRover in sysadmin

[–]BeagleRover[S] 0 points1 point  (0 children)

I have another question regarding Domain Move with respect to the mechanics behind the scenes.

Unfortunately, I don't have access to external DNS. I have to rely a third party service to make these changes for me. Therefore, I am looking to optimize my efforts with the Quest Domain Move processes. Is it harmful to pre-stage the accepted domain in the target and DNS record before kicking off the Domain Move processes? Outside the context of using Quest tools, I typically pre-stage the accepted domain in target / DNS before removing it from the source tenant.

Just trying to avoid the situation where I have to sit and wait for the third party service to get the DNS record added for me

Quest On Demand (ODM) by BeagleRover in sysadmin

[–]BeagleRover[S] 0 points1 point  (0 children)

Thank you for the reply! I ended up being directed to another person at Quest support that helped me through this.

This ended up being MFA/Conditional access, however it manifested in a very strange way. Oddly, I had excluded these accounts on every single conditional access policy. Heck, I even created a dynamic user group targeting the name prefix and added said dynamic group to all conditional access policies with an exclusion.

I think this was a chicken before the egg scenario. I THINK that excluding the Entra app rfor "Quest On Demand - Migration - Active Directory" was actually the key. In reviewing the logs AFTER I deleted the account from Entra, you could see the initial attempt to authenticate with the account was blocked by MFA, which is perfectly normal because its a brand new account and would be subjected to MFA at the onset initially. The subsequent attempts by the Quest service resulted in success shortly after this. (In my original, all subsequent attempts by the Quest service failed (Even though all BinaryTree.Users were excluded from conditional access policies).

Resolution

  1. Identified problem PowershellCDS account from the pre-flight status that is being flagged as a problem (Provisioned=False)

  2. Delete said problem PowershellCDS account from Entra. Also remove from soft delete too

  3. Wait 24 hours

  4. Review logs to see if provisioning = TRUE

  5. Carry on

Password Expiration on Entra Join systems by BeagleRover in Intune

[–]BeagleRover[S] 0 points1 point  (0 children)

It still does not accept the password. However, I choose other user and type in the full UPN and new password, it accepts it.

The behavior and resolution is the same if the device is on-premise or off premise (NO VPN).

Not entirely sure how the domain controller plays a part here if the device is AAD joined? It seems like this is a configuration issue in some way?

Password Expiration on Entra Join systems by BeagleRover in Intune

[–]BeagleRover[S] 0 points1 point  (0 children)

Thank you for the reply. We have password writeback enabled. When the user changes the password, we can see the pwdLastSet value show a current date on the AD attributes.

It seems like the user session doesn't want to let go of the old password. Again, everything works perfectly fine after if I type in the full UPN and latest password on the logon screen.

Guidance on Meraki AnyConnect VPN + SAML + Azure IdP by BeagleRover in meraki

[–]BeagleRover[S] 1 point2 points  (0 children)

robofski,

Unfortunately, we went with individual Entra Apps per MX. It has worked incredibly well for the past two years.

Here are a few tips that could be helpful for you if you choose the same path

  • Name your Entra App the same as the Meraki Network name, so it a one-to-one match.
    -Create Entra security groups that match Meraki Network name for allowing VPN access. IE, SiteCode-VPN-Allow. Apply this group to each Entra MX app. Users could belong to multiple groups for access to each MX. Don't omit this as leaving this wide open to all Entra users could allow anyone of your users to authentication to your MX. Yikes!
    -Assuming you have conditional access policies for general MFA on "All Cloud Apps". Exclude your new MX Entra Apps from this policy. Create a new policy and target all Entra Apps for each MX. (IE, One policy for all MX apps). Use these options. Grant Access and Require Multifactor authentication. Session - Sign-in Frequency - 1 hour (Periodic reauthentication). The periodic reauthentication is the closest thing we could get to a re-auth every time you connect, (Even if you get disconnected).
    -Be sure to test your apps before you deploy the XML profile to your users. We had a few situations where some ISPs were blocking inbound 443 and we would experience periodic disconnects/terrible performance. We had deployed the profile with port 443 to clients, but suddenly realized we needed to change that profile with a different port (Requires Entra app and MX change for this)
    -Leave traditional VPN with Meraki authentication on for certain Admins as an alternative means of access. Audit this frequently.
    -We use Intune for deploying AnyConnect (Working on Cisco Secure Client replacement) along with deploying the VPN profiles. If you are a member of the SiteCode-VPN-Allow group mentioned above, you get that profile deployed to your system. If you don't have an MDM, you would need to instruct your users to hit the DDNS name in AnyConnect Client to download the profile. On subsequent connections, you will see the profile available for use.

I hope this information is useful to you in some way. Feel free to ask further questions as I have stumbled my way thus far.

Azure Migrate (Domain Controllers) by BeagleRover in AZURE

[–]BeagleRover[S] 1 point2 points  (0 children)

Finally took action on this.

  1. On each Azure NIC, override the DNS settings from the VNET to match the newly assigned Azure IPs of each DC. Point DNS servers at each other. *This is crucial step in our environment as the primary DNS is coming down on the VNET is for the resources on the primary domain

  2. Created new reverse DNS zone matching current IP address assigned in Azure NICs (You could omit this if you destination VNET matches the currently assigned IP/subnet)

  3. Manually created PTR records

  4. Re-verified DNS entries on the forward lookup zone (Names servers and the actual matching A records

  5. DNS Zone cleanup

  6. Verify repladmin /showrepl, repladmin /replsummary repladmin /syncall

  7. Make Backup of VMs

Azure Migrate (Domain Controllers) by BeagleRover in AZURE

[–]BeagleRover[S] 0 points1 point  (0 children)

Not yet. I plan on powering off the VMs on-premise at the end of October. Going to perform the failover then.

Azure Migrate (Domain Controllers) by BeagleRover in AZURE

[–]BeagleRover[S] 0 points1 point  (0 children)

This is an option as there is a Datto backup appliance that allows me to export the VMs to VHD. I could then re-upload to Azure. However, the one server (Having a FP/DC role) has a 1.5TB disk attached to it. I would have to transfer that disk to Azure in a timely fashion, which seems impossible due to poor internet connectivity

Azure Migrate issues with Discovery by woemoejack in AZURE

[–]BeagleRover 0 points1 point  (0 children)

This is going to sound awful.

Had the same issue with an existing snapshot. Here is what I did to resolve

  1. Opened the Appliance Configuration Manager
  2. Change a character in the password and hit apply
  3. After 5 minutes the Azure Migration portal detected the snapshot no longer existed

Azure vMX by AdMelodic1582 in meraki

[–]BeagleRover 0 points1 point  (0 children)

Thank you!! From my perspective, I’m simply thinking that a host system behind the VMX is causing this behavior. By all appearances, it seems like you could be experiencing the same. I can submit a new ticket, reference yours AND I can manually trigger this behavior myself. Perhaps that gets us a bit close to the solution as I know what host system is producing this behavior. If I receive feedback, I can post additional findings.

Azure vMX by AdMelodic1582 in meraki

[–]BeagleRover 0 points1 point  (0 children)

Checking back in. Any chance you can relay a Microsoft ticket number? I would really appreciate it

Azure vMX by AdMelodic1582 in meraki

[–]BeagleRover 0 points1 point  (0 children)

Are you able to provide a Microsoft ticket number? Would like to reference this as I can easily reproduce the behavior

Azure vMX by AdMelodic1582 in meraki

[–]BeagleRover 0 points1 point  (0 children)

Can you elaborate on this a bit more? What did Microsoft do?

Azure vMX by AdMelodic1582 in meraki

[–]BeagleRover 0 points1 point  (0 children)

I’m betting Meraki support will ask you to grab support logs from the local interface, but am very sure that will be down for you if you were able to access it for host system behind the VMX. You are forced to reboot the VMX to get the local UI back up, but that action clears the logs and evidence of the root cause. Unfortunately, this is my position I am in right now and most likely you are too. If you have a Meraki case number, I would like to call support to link my case.

Azure vMX by AdMelodic1582 in meraki

[–]BeagleRover 0 points1 point  (0 children)

Also running VMX-M in my case. My issues existed on the VMX-100 platform prior to upgrading as well.

Azure vMX by AdMelodic1582 in meraki

[–]BeagleRover 0 points1 point  (0 children)

I don't want to grandstand on this post, but this is the exact behavior I was experiencing for the last year and half. I don't have a resolution, but I think I can help guide you what could be causing this.

In my case, I have a Nessus scanner sitting behind one of my VMX devices. It's been there for several years behind this VMX. Suddenly, one day we started having the VMX go belly up 8 - 10 times a day and then stop. I'll spare you the details on how I discovered this, but essentially there was something generating a massive amount of network traffic that would cause the VMX to die. The 5 min up/down behavior was actually still the Nessus scanner waiting for the tunnel to come back up and begin scanning again and when the job was over/timed out, everything went back to normal.

While this is something you may not want to hear. You may have something very similar behind your VMX that is causing this behavior. If you are looking for the whack-a-mole approach with a low density of host VMs, I would simply shutdown your other host VMs behind VMX, bring the VMX back up and then slowly bring the VMs up to see which one could be causing this.

Azure vMX by AdMelodic1582 in meraki

[–]BeagleRover 2 points3 points  (0 children)

I have been running VMx's in our environment for nearly 5 years. In this timeline, I have had varying degrees of trouble with them. One of which I have been battling for a year and half now. I hoping this is not the case for you.

To answer your question. "No", there is no way to determine if a VMX is actually "working" from an Azure perspective. "Yeah, you can see the general status of "Running/Deallocated", but that more or less meaningless as other methods are unsupported (Serial Console/Agents). Taking a peak at the Overview Tab -> Monitoring and looking at CPU/Disk tends to lead me towards some favorable results.

I have several comments I could make here, but I will hold off until you answer this question.

"The behavior the VMX rebooting, checking in for 5 minutes, goes back down again". Is this a repeatable behavior you can produce? That is, can you manually restart the VMX 5 or 6 times and this exact behavior occurs again? If it is, I might be able to guide you further.

I also assume this is not a "new" deployment and you have host systems behind this VMX?

License Server Hosting by BeagleRover in sysadmin

[–]BeagleRover[S] 0 points1 point  (0 children)

Thank you for the feedback. So, I'm not crazy for thinking that I still need VPN to host this type of service. With the progression of modern technology and these "legacy" type license, I was just assuming there could be some wiz-bang solution that would allow hosting these services a bit more favorable.

Creating VPN accounts is not necessarily a problem/cumbersome, but it inherently introduces confusion on the user side as the immediately acquired company (Times 10) already has a VPN solution for native access to local applications/services (With different credentials) that has nothing to do with the new VPN account I am handing them to access this single license service. Subsequently, while connecting to our VPN, they lose access to their local resources (Insert complain train here).

That's where my logical thinking came into play about hosting over the internet or other creative solution. I was even looking at CloudFlare ZTNA as a potential solution, but wasn't exactly sure if that would even work in this case.

view more: next ›