evasion

Success: changed details in customsettings.ini to show FQDN instead of single label domain name: JoinDomain=FQDN DomainAdminDomain=FQDN NetSetup.log shows success code now, also allow reuse of computer name works. thanks to reading this : https://learn.microsoft.com/en-us/answers/questions/2192023/window-11-24h2-cant-join-domain?page=14#answers

When replacing old computers with new, usual procedure is to image new computer with existing old computer name. That way new computer is placed in the same OU as the old one. Been like that since days of Windows XP. Now this latest version of Win11 24h2 is not happy with resolving domain name during imaging. NetSetup.log shows this: " NetpJoinDomainOnDs: Domain name is invalid, NetpValidateName returned: 0x54b". So domain join fails @ Recover from domain step. When using powershell script inserted instead of that step, it will join domain.

permissions do exist on the account used to join domain, it has delegated role. Domain security policy does allow re-use of existing computer accounts. As I said power shell script will join domain if existing computer account is re-used. "Recover form domain" step in task sequence no longer works as before if existing account is re-used.

Pretty much the same experience with 24h2 version. REcover domain TS fails (seen in logs) but script reports success, domain join does not happen if using existing computer name. No such issues with previous version 23h2. However, PS script does the trick, only problem is having to input creds manually, which is no longer "zero-touch" approach.

At long last, with some help from Microsoft, I have a solution to this specific "send as" issue. As described here, I only had to change this registry value (Office 365): Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Profiles\Outlook\0a0d020000000000c000000000000046] "00033d1b"=hex:00,00,00,00 which changes Address Book to "Custom", and as a result everyone can now send from delegated mailbox or shared mailbox, no problems. If, this setting is reverted to "01 00 00 00" which enables Start with Global Address List, then "send as" no longer works as intended. It only took 3 months to arrive to this simple fix. Why Outlook behaves in this way, I have no idea. No need to switch to new outlook or use web mail as workaround.

re replacement, it's not a cluster but 2 hyper v servers. have set up failover, and testing currently. Yes, diagnostic work has limitations, and in case of suspected hidden firmware bug, even more difficult. All hardware tests on both cluster nodes have passed.

Mellanox ConnectX-5 adapters. Back to back on 25 Gb link. HC cluster is now only used for testing in the hope it will reveal root cause of RHS crashing. When this service which is responsible for high availability is randomly crashing, it's a game over.

not sure if I'm on the right post, but similar updates related glitch had caused lots of headaches/stress. HC cluster with 2 nodes only 2 years old, was updated in January, after engineers checked all pre-requisites. On the day updates were completed, no problems, everything ticked green. Next day, random VMs were hanging, accessible only in Hyper v manager, while their network card was unresponsive, any attempt to disable/enable in hyper v manager RDP was just not responding. Event logs pointed to RHS service, Event ID 1146. Such VMs could not be controlled, and only way to recover them was to put the node in standby, drain roles if possible, and reboot the node. So much for failover clustering. Then when node was up, the VM which was locked by RHS, would sometimes work, but had to be fixed with chkdsk, and 3 VMs had to be rebuilt using ISO, or partially restored from backups. This instability continued several weeks, sometimes VMs would lock up overnight while backups were running. Good response received from support engineers, sometimes working out of hours or weekends. In the meantime rental hyper v servers being used to host all VMS, as original cluster is unstable, even after full rebuild of 2019 datacenter OS. Anyone with helpful input welcome, because root cause of "The cluster Resource Hosting Subsystem (RHS) stopped unexpectedly" is still not known? There are some event log errors pointing to Mellanox firmware...

What a surprise this morning, "send as" works fine just as it used to before this glitch last week. GAL search also works fine as it did before. Something got fixed in exchange online in the meantime, maybe it took longer for power shell command to apply GAL update.

Yes, root cause is that GAL search scope in Outlook client is now limited to only one address book. And yet search filter in default GAL is not changed, search just stopped working Monday for no apparent reason.

I don't know how this can be fixed, if GAL search no longer works as intended. It still has the same "pre canned" filter (catch all) which is supposed to find shared mailbox which exists in offline address book, down on the list under GAL.

Same issue here. think that root cause is that Outlook cannot enumerate GAL anymore. When "sending as" from shared mailbox, you have to go to to search for your shared mailbox account clicking 2x on From button, and refresh that way, otherwise you get error as seen above. Giving "send on behalf" permissions does not help. Because GAL search works fine in OWA, it can be workaround for while until root cause is fixed. And the root cause is in Outlook client, not being able to resolve GAL search anymore. Instead having to go for offline address book is not a solution, because your default online GAL must be up to date before it syncs with offline version. It's like your offline address book is now more up to date, which is weird. For some reason new version of Outlook client (slide toggle button in upper right corner) will resolve GAL search better and be able to send as, from shared mailbox, but the shared mailbox is no longer available in left pane in new Outlook. Adding new account (shared mailbox, delegated to "send as") will fail. Reverted to old version because new one is just like half baked cake. Nice looking cosmetically, but lacking in functionality. Not to mention that email profile adjustments in control panel don't work with new version.

There is however, this anomaly: "Turn off autocorrect misspelled words" under Regional and Language options (User Configuration, Administrative Templates, Control Panel): You will have to do the opposite of what description says, to make it work. Tested and confirmed! I do not understand how designers of GPO templates pass quality control stage.

discovered that this is just as good: C:\Windows\System32\msra.exe /offerra on local network where it can be controlled with gpo.

Another test today resulting in 50% success. One user can run it, another can not. So why is it that new version is so unreliable ?

Regardless of deployment method (power shell or Intune, including Webvew2) this still presents a challenge: - local administrator can run new Quick Assist - student user can run new Quick Assist - teacher user cannot run Quick Assist, it does not respond to mouse click. Looking like unstable software still, not clear why only some users can run it, and cannot deploy until issues are resolved. Event log (Application and Services logs>Microsoft>Windows>AppModel-Runtine>Admin): 0x80070057: Cannot create the process for package MicrosoftCorporationII.QuickAssist_2.0.6.0_x64__8wekyb3d8bbwe because an error was encountered while configuring runtime. [LaunchProcess] 0x80070057: Cannot create the Desktop AppX container for package MicrosoftCorporationII.QuickAssist_2.0.6.0_x64__8wekyb3d8bbwe because an error was encountered configuring the runtime

That is what I have discovered and power shell does deployment part well. However, new Quick Assist app only runs under local administrator or domain admin login. Obviously, some kind of "elevated privilege" is needed. Old app used to run fine under standard user context. Standard user has visibility of new app, it can be pinned onto taskbar, but when clicked, it just disappears into thin air... event log says: 0x80070057: Cannot create the process for package MicrosoftCorporationII.QuickAssist_2.0.6.0_x64__8wekyb3d8bbwe because an error was encountered while configuring runtime. [LaunchProcess] and 0x80070057: Cannot create the Desktop AppX container for package MicrosoftCorporationII.QuickAssist_2.0.6.0_x64__8wekyb3d8bbwe because an error was encountered configuring the runtime. Any comments on how to overcome this ? UAC is disabled in local security policy, so no issue with prompts.

O365 has an option to store email signatures in the Cloud. Outlook as part of Office 365 does not always offer this option. What we do not see in signatures window is "Choose Default Signature" option at the bottom of the window. See this image for reference. Current version on automatic updates (hopefully most recent) is: Microsoft® Outlook® for Microsoft 365 MSO (Version 2202 Build 16.0.14931.20128) 64-bit also seen here: Outlook roaming signatures (microsoft.com) Anyone missing this option (Choose Default Signature) is welcome to comment.

Glad I'm not only one experiencing issues with rdp connction to psfinancials. Connection is fine in browser each time, but it seems to disconnect every 20 min, user experience not very good to start with. When rdp file is downloaded and tested, it won't connect if user logs in with domain account. However if user logs in as local administrator, it works fine. Error that currently cannot be fixed using domain account login looks like: Component name:CClientProxyTransport, :: 'Gateway Error' in CClientProxyTransport::SetErrorStatus at 2853 err=[0x80004005], Error code:0x80004005 and Component name:CAAHttpClientTunnel, :: 'Workspace ID was obtained, but it is not formatted as a GUID (PSFCB02.PSFCLOUD.COM)' in CAAHttpClientTunnel::ObtainWorkspaceId at 3766 err=[0x0], Error code:0x0 and Component name:CAAClientAdapter, :: 'm_spHelper->ReadCreds failed' in CAAClientAdapter::CreateTunnel at 380 err=[0xffffffff], Error code:0xFFFFFFFF And it sometimes won't even connect as local administrator, same errors seen. Tried various fixes in gpo/registry - nothing seems to work. Update: this seems to have worked: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa] "LmCompatibilityLevel"=dword:00000003 Update This has only helped on one workgroup computer but on domain computers it still only works under local admin login.

just tested latest Win10 education, created MDt deployment sequence and was happy to see imaging complete as fast as Windows 10. Logged in no problems, and pulled latest updates. There were only 3 and after reboot no more logins. Domain login just hangs on welcome screen (preparing windows please wait...) and local admin can log in to desktop but no working menu with tiles as on first login before updates. One of them was servicing stack which cannot be removed. I did not bother trying to remove other updates to see which one broke desktop so I re-imaged the computer with Windows 10 so it can be used for other testing purposes. So, not really rushing to roll out this deployment, at least until these glitches are ironed out. Previous attempt with first release on October 5th also broke desktop after couple of updates landed. I have seen some posts re broken taskbar dated in October and was hoping such updates have been removed but it seems not.

just got 50 device based licences for O365 software. Plan was to remove current O365 installation with user based licence and install device based licensing version (only a small change in config.xml). Difficult part is selecting computers in Azure AD to be members of AD security group to which these new licences will apply. One would think this would be straightforward thing to do. Far from it, because if you search Azure AD for domain joined devices, single computer will appear in multiple instances as different guids thanks to using Azure AD Connect whereby each computer gets registered in multiple quantities, each one via different user activating O365 previously. Nightmare you just cannot resolve. Rolled back to Office 2019 which can be used for exams/tests without Internet connectivity (restricted logins). I have no idea how Microsoft expects users to assign device based licences if they are not able to select single device accounts from Azure AD.

just to point out how difficult product to implement in secure environment this is (User Voice since 2015 - no movement since then)..

Is this going to help if I only have slow response form wizard.hta script during initial winpe loading stage? Both 64 and 84 bit PE images are regenerated with fresh drivers and when F12 is pressed and PE starts to load I see wizard.hta presenting blank screen for couple of minutes, before it loads interactive screens to enter credentials. Any thing else to speed up this script?

I have just hit the same "brick wall" of having OneDrive working with C: drive hidden but not restricted. So far in a test OU it works spot on as long as C: is only hidden, try to restrict access and OneDrive stops working as expected. So, no way to have unsecure network (security by obscurity) for me. Drop the whole OneDrive project or what? Just cannot risk another malware vector and have sleepless nights....

I have been convinced that is is good network practice to restrict access to OS drive (c:) via GPO so that computers are locked and cannot be hacked easily. This applies to student users only. I cannot comment on your network security though.