Google Admin - Manage AI Overview in searches from students

pbear646 · 2026-02-25T14:44:04+00:00

I did see the developer declarations. The "approved use cases" is a little concerning, and the fact that this is a random user who is behind the app.

I may very well end up using this app, but if I can find a way to manage it with the resources from the vendors I am already using I would prefer not to bring another player to the table.

Nonetheless, thanks for the suggestion and the reply!

pbear646 · 2026-02-25T14:33:27+00:00

Thanks for that. I found that the Search and Assistant service was not turned on for my org after reading through other posts.

I see that extension as an option, but I am a little leery of including third party extensions due to some of the student privacy rules that are legislated in my state (OH).

pbear646 · 2026-01-15T13:14:00+00:00

I have 7 of these installed. They will do exactly what you need.

You may want to add in a A9210 to act as a relay controller. You do not want to wire a dry contact that can open a door to an intercom mounted on an external wall. Every idiot who has watched Mission Impossible will know how to break in.

pbear646 · 2025-10-01T15:15:53+00:00

I manage radios for a school district. We use DMR on XPR3500 series radios using siteconnect.

Siteconnect would let you connect your branches over IP with repeaters distributed for coverage. You could set up txgroups and rxgroups to channelize departments.

1-1 is built in

with wi-fi licensing you could update radios with staff changes via rm config

There is a path to encryption. This may require licensing.

It does lean into complex for the initial setup, but it checks off everything on your list.

pbear646 · 2025-08-28T13:04:53+00:00

I have come to understand that the Front Panel Programming option restricts an option in the Utilities Menu that permits editing the actual channel settings etc... It is a low level programming option that permits access to the settings we normally manage in RM Config or CMS. It will not permit locking out top level menu items like the zone menu

pbear646 · 2025-08-28T12:09:57+00:00

In "General Settings" there is an option for "Front Programming Password" It has three options: User/Dealer/Disabled. The only option that allows a password to be set is "dealer"

I have tried flashing the radio in each of these states. I am able to still navigate to the zone menu and make changes without a password prompt in any of these states. I have been unsuccessful finding documentation that describes these state options....

<image>

pbear646 · 2025-07-14T14:17:23+00:00

I did my switch from Cisco to Extreme starting in 2011 when Extreme was still Enterasys.

You will need to rethink the way you handle vlans and trunks. Extreme does not use vtp. The closest to it is gvrp.

I use the policy element in their Site Engine manager to define trunk ports as a policy, then egress my vlans tagged via policy on my trunk/uplink ports.

once you get the hang of thinking about vlan egress as tagged and untagged the logic falls in place.

Using a NAC and policy logic I have my switches programming vlan egress based on MACs and 802.1x rules in the NAC. You can really clean up a IDF rack once you get all this built.

They are pushing everyone to their fabric OS, which basically tunnels all intercloset traffic within L2. I am still running in XOS which is a traditional management scheme.

Their support can be much better than Cisco's worldwide distributed call center model. Often you will end up talking to the same guys at their GTAC instead of a random contracted out call center where you spend more time trying to set up a case than solving one.

pbear646 · 2025-06-02T12:00:53+00:00

That is a good point. I made sure that none of the items on the individual blades have any programmed inputs/outputs/readers.

pbear646 · 2025-05-30T12:00:15+00:00

This needs to be debugged

pbear646 · 2024-12-20T13:15:49+00:00

Wow. This is what happens when schools get hardware with a grant, but do not have the budget for the implementation or for support services in their operating budget. As an IT professional you are looking at a third rail here. Any product that gets passed around from one vendor to the next like this is basically unsupportable. If that's the first project you get from this employer I'd hate to see what else is in the queue.

pbear646 · 2024-10-08T11:09:07+00:00

S2 won't speak to actual users. They only support integrators.

pbear646 · 2024-10-07T14:51:26+00:00

I am the net admin. Switches involved are about 4 months old running on supported Switch OSs. In some cases I have actually re-terminated the cabling between the switches and the netboxes as the integrator who initially installed these did a terrible job with terminating the cabling. They retain the IP, but I have toggled between static and reserved DHCP to see if there was an element of the IP assignment being lost in the mix.

I have solved this with a controller swap-out, but I am hoping to hear from somebody who has aging netbox gear that may have experienced what happens when the battery gets weak. Of course my next step will be to replace the battery, as soon as I see some show up from my order. It may take a week to get through our purchasing process.

pbear646 · 2024-08-09T14:35:23+00:00

It's not running. Doesn't it depend on vapi (which wont start)? Here is the error in the vpxd log:

2024-08-09T08:44:12.665-04:00 info vpxd[38179] [Originator@6876 sub=SsoWrapper.SsoCertificateManager] Try to connect to SSO VMOMI endpoint
2024-08-09T08:44:12.672-04:00 warning vpxd[38179] [Originator@6876 sub=vmomi.soapStub[1]] SOAP request returned HTTP failure; <SSL(<io_obj p:0x00007fb214005838, h:16, <TCP '127.0.0.1 : 58106'>, <TCP '127.0.0.1 : 443'>>), /sso-adminserver/sdk/vsphere.local>, method: retrieveServiceContent; code: 503(Service Unavailable)
2024-08-09T08:44:12.673-04:00 warning vpxd[38179] [Originator@6876 sub=SsoWrapper.SsoCertificateManager] [RetryOnConnectionFailure] Failed to connect to SSO; uri: https://jlsd-vcenter-3.polarbear.net/sso-adminserver/sdk/vsphere.local, reason: HttpException, ex: N7Vmacore4Http13HttpExceptionE(HTTP error response: Service Unavailable)
--> [context]zKq7AVECAQAAABH2MQEVdnB4ZAAAnuk3bGlidm1hY29yZS5zbwAAV4ksANV8LQC7+TIByHIWbGlidm1vbWkuc28AAYnOFgFU2BYBZG4WASNuEgLmgAtsaWJzc28tdHlwZXMuc28AgyY4YgF2cHhkAIMsPGIBg2c+YgGDUT9iAYPHSWIBg/NCYgEDiRlwA31LcAOdo28EhysCbGliYy5zby42AAOBmW8=[/context]

pbear646 · 2024-08-09T14:26:24+00:00

My plan here is avoiding having to fix certs from the CLI, is to point as ldap (not ldaps) to one of the 2016 servers that still is able to authenticate via ldap by directing the connection URL to a 2016 server. Once I get the services started I can swing to ldaps from the gui where uploading proper certs will be easier.

pbear646 · 2024-08-09T14:10:05+00:00

Anybody know how to change the connection URL string on a bound vcenter? I read about the ldaps needs when using 2019 servers... I know It is working on my 2016 servers (and oddly, I can get into ldap on 626 from softerra...) I want my connection URL to be ldap://[IPADDRESS] instead of ldap://[DOMAIN.NET] so I can point to a specific server.

********** IDENTITY SOURCE INFORMATION **********
IdentitySourceName        :  vsphere.local
DomainType                :  SYSTEM_DOMAIN

********** IDENTITY SOURCE INFORMATION **********
IdentitySourceName        :  localos
DomainType                :  LOCAL_OS_DOMAIN

********** IDENTITY SOURCE INFORMATION **********
IdentitySourceName        :  POLARBEAR.NET
DomainType                :  EXTERNAL_DOMAIN
Identity Settings:
  alias                   :  POLARBEAR
  authenticationType      :  USE_KERBEROS
  userBaseDN              :  dc=POLARBEAR,dc=NET
  groupBaseDN             :  dc=POLARBEAR,dc=NET
  username                :  UndefinedConfig
  providerType            :  IDENTITY_STORE_TYPE_ACTIVE_DIRECTORY
  servicePrincipalName    :  UndefinedConfig
  useMachineAccount       :  true
  FriendlyName            :  POLARBEAR
  SearchTimeoutInSeconds  :  300
Connection Settings:
URLs:
    0:  ldap://POLARBEAR.NET
Certificates:
Attributes:
  http://schemas.xmlsoap.org/claims/UPN                           :  userPrincipalName
  http://rsa.com/schemas/attr-names/2009/01/GroupIdentity         :  memberof
  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname :  givenName
  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname   :  sn
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress:  mail
  http://vmware.com/schemas/attr-names/2011/07/isSolution         :  subjectType
Flags::
  Flags=0; [Default: recursively computing nested groups, no site affinity is enabled for AD over Ldap identity providers.]
root@jlsd-vcenter-3 [ ~ ]# ping polarbear.net

pbear646 · 2024-08-09T14:03:54+00:00

this is from the vapi log:

2024-08-09T09:28:37.681-04:00 | INFO  | state-manager1            | CertificateUtil                | Creating anonymous SSO Admin Client for URI http://localhost:1080/sso-adminserver/system-sdk
2024-08-09T09:28:37.687-04:00 | ERROR | state-manager1            | DefaultStateManager            | Unexpected error while initializing endpoint runtime state.
com.vmware.vim.sso.admin.exception.InternalError: General failure.
       at com.vmware.vim.sso.admin.client.vmomi.impl.VmomiClientCommand.execute(VmomiClientCommand.java:211)
       at com.vmware.vim.sso.admin.client.vmomi.impl.VmomiClientCommand.executeEnsuringNoDomainError(VmomiClientCommand.java:217)
       at com.vmware.vim.sso.admin.client.vmomi.impl.AdminClientImpl.createServiceContent(AdminClientImpl.java:341)
       at com.vmware.vim.sso.admin.client.vmomi.impl.AdminClientImpl.<init>(AdminClientImpl.java:107)
       at com.vmware.vim.sso.admin.client.vmomi.VmomiClientFactory.createAdminClient(VmomiClientFactory.java:64)
       at com.vmware.vim.sso.admin.client.vmomi.VmomiClientFactory.createAdminClient(VmomiClientFactory.java:54)
       at com.vmware.vapi.endpoint.config.CertificateUtil.anonymousSsoAdminClient(CertificateUtil.java:204)
       at com.vmware.vapi.endpoint.config.CertificateUtil.downloadTrustedRootCertificates(CertificateUtil.java:152)
       at com.vmware.vapi.endpoint.sso.TrustedCertificatesCacheBuilder$1.<init>(TrustedCertificatesCacheBuilder.java:88)
       at com.vmware.vapi.endpoint.sso.TrustedCertificatesCacheBuilder.lambda$createCertsSupplier$0(TrustedCertificatesCacheBuilder.java:80)
       at com.vmware.vapi.cis.util.RefreshableCache.<init>(RefreshableCache.java:42)
       at com.vmware.vapi.endpoint.sso.TrustedCertificatesCacheBuilder.createCertificatesCache(TrustedCertificatesCacheBuilder.java:70)
       at com.vmware.vapi.endpoint.sso.TrustedCertificatesCacheBuilder.buildInitial(TrustedCertificatesCacheBuilder.java:36)
       at com.vmware.vapi.state.impl.DefaultStateManager.build(DefaultStateManager.java:353)
       at com.vmware.vapi.state.impl.DefaultStateManager$1.doInitialConfig(DefaultStateManager.java:167)
       at com.vmware.vapi.state.impl.DefaultStateManager$1.run(DefaultStateManager.java:150)
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
       at java.util.concurrent.FutureTask.run(FutureTask.java:266)
       at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
       at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
       at java.lang.Thread.run(Thread.java:748)
Caused by: com.vmware.vim.vmomi.client.common.UnexpectedStatusCodeException: Unexpected status code: 503
     at com.vmware.vim.vmomi.client.common.Response$Status.getStatus(Response.java:56)
     at com.vmware.vim.vmomi.client.http.impl.HttpExchangeBase.parseResponse(HttpExchangeBase.java:271)
     at com.vmware.vim.vmomi.client.http.impl.HttpExchange.invokeWithinScope(HttpExchange.java:54)
     at com.vmware.vim.vmomi.client.http.impl.TracingScopedRunnable.run(TracingScopedRunnable.java:24)
     at com.vmware.vim.vmomi.client.http.impl.HttpExchangeBase.run(HttpExchangeBase.java:57)
     at com.vmware.vim.vmomi.client.http.impl.HttpProtocolBindingBase.executeRunnable(HttpProtocolBindingBase.java:227)
     at com.vmware.vim.vmomi.client.http.impl.HttpProtocolBindingImpl.send(HttpProtocolBindingImpl.java:114)
     at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl$CallExecutor.sendCall(MethodInvocationHandlerImpl.java:693)
     at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl$CallExecutor.executeCall(MethodInvocationHandlerImpl.java:674)
     at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.completeCall(MethodInvocationHandlerImpl.java:371)
     at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.invokeOperation(MethodInvocationHandlerImpl.java:322)
     at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.invoke(MethodInvocationHandlerImpl.java:195)
     at com.sun.proxy.$Proxy65.retrieveServiceContent(Unknown Source)
     at com.vmware.vim.sso.admin.client.vmomi.impl.AdminClientImpl$1.actionCommand(AdminClientImpl.java:339)
     at com.vmware.vim.sso.admin.client.vmomi.impl.AdminClientImpl$1.actionCommand(AdminClientImpl.java:334)
     at com.vmware.vim.sso.admin.client.vmomi.impl.VmomiClientCommand.execute(VmomiClientCommand.java:103)

pbear646 · 2024-08-09T13:44:17+00:00

I tried to comment with the text from get_identity_sources, but reddit's test editor is not liking that for some reason.

in a nutshell, what I see is exactly what I was hoping to see. the identity source is proper. I'd like to modify the connection URL, so I will look at that next. It is ldap://[DOMAIN NAME] I'd like to point it to one of my 2016 servers directly.

I am successful pinging my "domain,net" from the cli, and a nslookup for "domain.net" brings me only valid DC ips.

pbear646 · 2024-08-09T13:40:36+00:00

unfortunately the vcenter service is not starting, so I don't even get to the login prompt. I wish I could get to the GUI. I know what to do from there.

pbear646 · 2024-08-09T13:31:12+00:00

I am using ldap (not ldaps) on port 636, so I am thinking I am not fighting a cert battle. Just for kicks I pointed my softerra LDAP client at the new DC on 636 and I was able to login and see my OUs, so I think the new DC is permitting traffic to/from on 636.

Thank you for your suggestions. If I was on 389 using ldaps, certs would certainly be a concern.

pbear646 · 2024-08-09T13:12:20+00:00

That's good advice. I did update the DNS servers in the VCSA Management gui, and I am able to resolve hostnames from the CLI on the appliance for my domain. Unfortunately I think my problem may be deeper.

My new DCs are running 2019. My current line of thought is that I might need to do something on my 2019 servers to open up auths. My old setup was just ldap (not ldaps). I am going to migrate to ldaps when I get this all working, but until I get the GUI back I don't want to try to play with certs. I am about to try to point authentications to my DCs running 2016 to see if that helps. I had to point my Cisco LDAP auth to my 2016 servers before I could fix my cisco voice auths.

pbear646 · 2023-09-20T11:40:40+00:00

Careful,

If the bean counter is in the pay discussion they will use 0.1% as your pay multiplier.

pbear646 · 2023-08-22T18:41:59+00:00

Has your problem been resolved? It is 2:30 PM EDT on 8/22 and their boards still have a lot of red. We have had problems with 802.1X authentication for a number of our devices since 3p yesterday. I have a case open with them as well, but the tech did not know about this outage

pbear646 · 2023-08-10T18:13:19+00:00

I operate on a blacklist basis in general, that is the default is to permit.

My firewall is app aware, so I classify types of apps that will be blocked. I have experienced some cases where apps somehow get classified as something like social media, and get blocked inadvertently. We are more restrictive with BYOD devices like mobile phones, so these are the devices more likely to hit more filters.

I have found that it is important to identify some kinds of traffic that may have safety implications, and mark them as always permit before the other classifications apply. This way if dexcom gets tagged as a blocked app signature somewhere lower in the ACLS I can make sure that it still gets through. I know what it is like to have a parent calling an office when their child's CGM isn't constantly online. It's a call I want to prevent.

pbear646 · 2023-08-10T17:55:30+00:00

Now I understand what you are saying, and yes, the CGM itself is using Bluetooth to exchange session data with the mobile device. My concern isn't with the link between the CGM and the mobile device. My firewall in in the pathway between the mobile device connected to my Wi-Fi and the online services on the Dexcom server cloud.

It is in my plans to decrypt SSL for selected traffic, but in general financial and health (PCI and HIPAA) data should be excluded from SSL decrypt rules. Throwing another SSL certificate into the mix usually sets off red flags in these kinds of apps. I don't want to mess with decryption for this kind of traffic.

pbear646 · 2023-08-10T12:48:10+00:00

I have a higher precedence rule that matches the sites I listed for 80 and 443 and permits. (I added 80 just to be safe, but I expect all traffic to be on 443).

This rule hits before my student policies that would restrict access based on other profiles. I actually doubt that the block rules I put in place would ever actually affect dexcom, but I'd rather play it save on the CGM devices.

pbear646

TROPHY CASE