Office v2508 feature update (new vbe7.dll) breaks library compatibility with LTSC VL versions
Since the Jan 2026 updates, some `accde` or `mde` libraries built with the semi-annual enterprise channel (v2508, Build 19127.20484) can no longer be used with the volume-licensed version of Office LTSC (tested with the Jan 2026 release of Office 2024 LTSC VL, v2408, Build 17932.20638). The reason for this seems obvious: The v2508 feature update contains an updated vbe7.dll. Apparently, this change is backwards-compatible (code compiled with the old dll will run with the new dll) but not completely forwards-compatible (code compiled with the new dll might not run with the old dll, even if the new RegExp class is not used). That's a problem for us. We can't just tell our customers to upgrade, because those with an Office 2024 LTSC volume license already use the latest version available to them. Does Microsoft consider this a bug or "by design"? If the latter, what is Microsoft's recommendation for software vendors who want to build software that runs on all currently-supported versions of Access? We currently plan to work around this issue by installing v2502 of the semi-annual enterprise channel on our "build VMs" (32 and 64 bit) and use those to build our software. (Reverting dev machines to an old Office version is not an option for obvious security reasons.) Repro On a PC with v2508 or newer: 1. Create a new mylibrary.accdb with a module with the following code: Public Function GetColorCode() As Long GetColorCode = vbRed End Function 2. File/Save as/Create accde. 3. Copy mylibrary.accde to a PC with v2507 or older (for example, with the current version of Office 2024 LTSC volume license). On a PC with v2507 or older: 4. Create a new database. 5. Create/Module/Tools/References 6. Add a reference to mylibrary.accde 7. Add the following code to the module: Sub Test() Debug.Print GetColorCode() End Sub 8. Debug/Compile Expected result: The database compiles. Actual result: "Compile error: Can't find project or library". The "references" window opens automatically and highlights "mylibrary". Notes We are not library developers, but we are still impacted by this issue, since the software we ship consists of a (modifiable) startup mdb referencing an (unmodifiable) mde containing the business logic. If you want to try to reproduce this issue but don't have a volume license of Office 2024 LTSC lying around (we certainly don't), you can install a trial version with the Office Deployment Tool and the following configuration file: <Configuration> <Add OfficeClientEdition="64" Channel="PerpetualVL2024"> <Product ID="ProPlus2024Volume"> <Language ID="en-us" /> </Product> </Add> </Configuration>
Can a "Qualifying desktop OS" be paper only?
Some VL licensed Windows editions require a pre-existing "Qualifying desktop OS", which must be one of the consumer-grade editions. Question to VL experts is if that "Qualifying desktop OS" can take the form of a paper only license kept on file and reserved for filling that role . The scenarios considered are new virtual machines and clean OS install on physical hardware (which may or may not have an irrelevant OEM key in BIOS). Because installing and immediately wiping an OS image of lower quality/value on each machine would be an obvious waste of time . Also, when the VL licensed OS is an LTSC edition dated at least 1 month before install, automatic consumer grade updates to latest consumer channel version could make installing the chosen LTSC edition technically a "version downgrade in place" which tends to not work (at least for past Windows versions).
Can LTSC 2019 run perfectly on surface book 3
As the title says, I'd like to know if LTSC 2019 will run perfectly on a Surface book 3, such as install the required drivers, and be able to use the Surface's features, such as the separation of the keyboard from the screen, or touch support. In this website,https://support.microsoft.com/en-us/surface/surface-supported-operating-systems-9559cc3c-7a38-31b6-d9fb-571435e84cd1#bkmk_surfacebook, it is shown that surface book 3 supports OS version 1903 and above, and LTSC is based on 1809, so I want to ask
[LTSC] Windows Hello Facial Recognition - Installation OR Repair
Hello Tech Community, Recently, I discovered that Windows Hello Facial Recognition is either disabled or removed from Windows 10 Enterprise LTSC 2021 (21H2), and after a skim of the archives, could not find any method to install Windows Hello to these devices. Q: Are/Is the device(s) in question compatible with Windows Hello Facial Recognition? A: They are by the OEM, claiming that an IR module is specifically installed in each unit with compatibility guaranteed. Q: Are/Is the device(s) in question using the correct Windows Hello Facial Recognition-compatible driver? A: The drivers have been installed in full, and Windows prompts users to set up Windows Hello Facial Recognition rather than reporting that no compatible device is installed. Q: Are/Is the device(s) in question affected by any OEM/user modifications which could inhibit Windows Hello's ability to function properly? A: Microsoft Edge has been uninstalled (using the built-in uninstaller bundled with LTSC 2021) from the device(s), however no non-standard (including Enterprise-specific) settings/programs have been altered outside of that. Q: What issue is occurring when attempting to configure Windows Hello Facial Recognition on the device(s)? A: The introduction to Windows Hello Facial Recognition simply force-stops/crashes when Get Started is pressed, as if an application is not present. This may also be a missing Universal Windows Program (.uwp), as no other UWPs are present in this install, as far as I'm aware. My question to you: Is it possible to install or repair Windows Hello (the combined package, preferably) to this installation of Windows 10 Enterprise LTSC? Thank you, MakeineerExchanging Experiences - Overview Practice Licensing Windows Server Core LTSC CBB LTSB
Originally Written in Brazilian Portuguese General Objectives of the Article Discuss observations and what would be the best licensing channel options considering critical mission environments. Introduction From Windows Server 2016, Microsoft has made available until the writing year of this article, 3 licensing channels of the Windows Server product family. Looking in general, the items below analyze from the operational point of view the available licensing models to choose from the point of view. LTSC - Long Term Service Channel The mode of licensing and support of products that many organizations are already used to. 5 years of dedicated support + 5 years of extended support. 5 years of dedicated support including support for new feature updates, functions, fault correction packages, improvements, and security with Microsoft through contract or loose call. Near the end of the 5-year period of dedicated support for a product version, a new product version is released. 5 years of extended support, with limited fixes support and support only for critical security features, without caller support with Microsoft. Products from the Windows Server, Windows 10, System Center, Office Server, Developer Tools families are available on this channel and virtually all others that are not "Product as a Service". CBB - Current Branch for Business Focused on fast-released scenarios, served on the Semi Annual Channel model. 6 months of dedicated support + 6 months of extended support. Windows Server, System Center, Windows 10 family products are available on this channel and other products offered in the "Product as a Service" model. LTSB - Long Term Service Branch Focused on scenarios that are not necessary or have limited possibilities for product updates, such as ATMs, Hospital Machines and embedded systems electronics. Update support has a longer delivery range, such as Windows 10 LTSB, updates are delivered at 2-year intervals, without immediate support for DirectX updates and other common resources for daily use, but unusual to limited scenarios. Products from the System Center, Windows 10 families are available on this channel and others to support embedded equipment solutions. Notes Before Using Windows Server Core in Production Before installing the Windows Server product in core mode, a careful observation of the licensing type is required, since depending on the "WorkLoad" that is allocated to the server, application, module, or system, the type of licensing can require applications for build updates that can operate, technically or financially the solution allocated on the server. A licensing version that requires constant updates not supported by the application can compromise the performance or availability of the application or solution, as well as vendor support. A large-period feature upgrade veto may not bring new features or support to essential application APIs. The best scenario is to align product usage with application teams to identify the best appropriate licensing version, analyzing the compliance of the current scenario. Taking into account experiences of operations production environments in critical missiles, services based on solutions such as Microsoft ADDS infrastructure services, Microsoft ADCS Subordinate (Non-Root), Microsoft DNS StandAlone, or Active Directory Based, when allocated to dedicated servers can take advantage of better control and less impact of "Server Core" installation mode with lower support period licensing and fast releases, CBB licensing, provided in High Availability. Implant products with larger scopes, even if they are infrastructure, and that have a higher level of knowledge, specialized companies for the provision of support, may not be good canditadas in the mode of rapid releases, but rather to the channel of longer support period, products such as the System Center family, recently Exchange Server,SharePoint Server, are examples, given the need for documentation and compatibility analysis in heterogeneous environments. Another observation is that the "Server Core" installation mode targets a "Client->Server" consumption model, that is, the server allocates the active load, as expected, but the management tools are executed and allocated, installed, on the client machines of the administrators or remote management infrastructures. "WorkLoad"s, applications that require management via Microsoft RDP for the server that hosts it and that do not have remote-management consoles or that are unable to manage remotely, may not be good canditades to hosting on servers in mode " Server Core." This is an open discussion channel share below the observations and options. Referece: docs.microsoft.com/en-us/windows/deployment/update/waas-overview Originally Written in Brazilian PortugueseTroca de Experiencias - Adotando o Windows Server Core
Escrito originalmente em Portugues Brasil Desde o Windows Server 2008 R2, a Microsoft disponibiliza uma versão de instalação da linha de produtos Windows Server que traz maior ganho ao negócio de acordo aos cenários de uso do produto para construir uma solução. O Windows Server Core é um modo de instalação do produto Windows Server a partir da versão 2008 voltado a usos de diminuição da superficie de ataques, consumo de disco e em resumo o que pode ser observado como diminuição do uso dos recursos computacionais (CPU, RAM, Disco, NetWork) dedicados a tarefas não essenciais para dedica-los aos objetivos de uso do servidor. Em resumo o método de instalação Server Core remove features gráficas exigindo que o Sistema Operacional e as aplicações sejam controlados por uma equipe de profissionais que compreendam a administração de recursos e funções dos escopos de produtos Microsoft via Windows PowerShell, utilitários de linha de comandos, Prompt de Comando, Tasks Manager ou Bloco de Notas. Analisando a efeitos práticos da implantação implementada em um ambiente de produção real e de missão crítica, este método de instalação evita, devito as limitações de gerenciamento local, acessos clientes ao servidor via Microsoft RDP, o que elimina a necessidade de criar sessões dedicadas a cada novo cliente que se autentique ao servidor para gerencia-lo, por efeito evita usos desnecessários dos recursos computacionais do servidor. Considerando o comportamento de cada nova conexão cliente feita ao servidor via Microsoft RDP ou local, softwares que usufruem de personalizações das sessões de usuário iniciam processos dedicados a sessão e muitos destes processos continuam em execução mesmo se a sessão cliente estiver em estado de desconectado, ou seja, está autentica, porém bloqueada no servidor, devido ao cliente apenas fechar o software cliente que use o Microsoft RDP ou outra configuração especifica como cenários de configurações do Microsoft RDS RemoteApp. Antivirus e softwares com comportamentos que se enquadrem em "StateFull" são os maiores causadores do comportamento de elevar consumos de recursos computacionais em sessões de usuários. Porém como todo o leque de tecnologias, existem cenários de usos adequados à este método de utilização e mesmo algumas aplicações da Microsoft possui algumas limitações na operação sobre este modo de instalação da linha de produtos Windows Server. Aplicações como Skype for Business, Azure AD Connect, Exchange Server 2016 são exemplos de produtos e soluções que mesmo diante das evoluções da linha Windows Server possuem limitações em algumas de suas versões por não possuírem suporte ao modo de instalação Server Core. Devido as limitações de uso das interfaces de gerenciamento, faz-se necessário uma infraestrutura de gerenciamento dos servidores em modo de instalção "Server Core", principalmente em ambientes de implantação em larga escala, com grandes distâncias físicas, limitadas por velocidades de links ou com equipes com limitações de conhecimentos especificos por qualquer que seja o motivo. Diversas ferramentas da Microsoft podem-se aplicar a gerenciar este cenário de servidores, porém uma infraestrutura de gerência fornece apoio quando fora dos limites de conexão da corporação, poder manter tarefas de rotinas em execução sem consumir demansiados recursos computacionais dos servidores de aplicações ou componentes das soluções. Nem todos profissionais de escopos de Microsoft realmente conhecem os caminhos corretos de operação destas ferramentas, como de que maneira consultar a documentação das sintaxes de uso ou os limites uso destas ferramentas. À exemplo do Windows PowerShell, nem sempre os cmdlets iniciados por "Get" são para consultas, "Get-Certificate" obtém um novo certificado de uma autoridade certificadora. Este artigo visa de maneira suscinta iniciar um diálogo a adoção coerente e efieciente de servidores da linha de produtos Microsoft Windows Server no modo de instalção "Server Core", porém de forma a possibilitar equipes com limitados conhecimentos aderir ao modelo aprendendo mediante a intimidade com a produção. Escrito originalmente em Portugues Brasil
