Missing entry in Fortigate Application Filter ROOT.CERTIFICATE.URL and OCSP source of W10 Setup failing

Fortigate Application Filter Certificate wrong/missing Entry sample for an important laptop driver (W10 Deployment fails because of signed Driver Revocation Lookup)

OR HOW a missing small ENTRY I a FORTIGATE FIREWALL IPS/APP filter can ruin your Windows 10 OS-Deployment work.

 

Reason: Missing entry in Fortigate Application Filter "ROOT.CERTIFICATE.URL" and "OCSP" source of failing deployment

 

Windows 10 Deployment with commercial Deployment Products (This includes HP client hardware, Microsoft SCCM, Landesk or Ivanti Frontrange).

During the Unattend phase the driver for MASS storage or NIC does a Certificate Revocation Lookup. However the as sample mentioned

URL pki.infineon.com (Hardware Driver URL, CRL FQDN) is missing in Fortiguard definitions. Thus the Fortigate does block the access to WAN. Since this is an early setup phase of W10, group Policy or special GPO do not pull at that moment.

 

Fortigate has already missed several PKI URL the last few months confirmed by ticket resulting in large trouble and delay on client and Server OS of customers who route their Client or Server traffic through Web proxy and because of security do not want to route computer account proxy traffic standard to the proxy.

 

Why this is so important. Why this is generating a lot of work and trouble for OS-Deployment teams.

 

The normal way in larger companies is that all outgoing traffic from client VLAN goes to Firewall which it blocks. All Web/Application/Socks traffic that should go outside goes to a Proxy, Web filter.

Because in early phase of Deployment those options are not set already and normally not needed. However if the driver is older than the Expiration of the Code Signing Certificate W7/W10 will check

The Certificate Revocation list from WAN/Internet. If that fails it may refuse to integrate the driver in Windows PE or early Windows Setup phase. If example this is a driver which

handels NIC (network) or mass Storage driver (Disk) they deployment can't run through this early process.

 

 

 

Workaround:

URL we need open in our sample: pki.infineon.com which prevents a complete Enterprise Deployment system to fail

 

 

 

Sample from Fortigate for other Certs they missed:

 

F-SBID( --name "Root.Certificate.URL_Custom"; --protocol tcp; --app_cat 17; --service HTTP; --flow from_client; --pcre "/(crl\.microsoft\.com|\.omniroot\.com|\.verisign\.com|\.symcb\.com|\.symcd\.com|\.verisign\.ne t|\.geotrust\.com|\.entrust\.net|\.public- trust\.com|\.globalsign\.|\.digicert\.com|crl\.startcom\.|crl\.cnnic\.cn|crl\.identrust\.com|crl\.thaw te\.com|crlsl\.wosign\.com|www\.d\-trust\.net)/"; --context host; --weight 15; )

 

In our case:

 

F-SBID( --name "Root.Certificate.pki.infineon.com"; --protocol tcp; --app_cat 17; --service HTTP; -- flow from_client; --pcre "/(pki\.infineon\.com)/"; --context host; --weight 15; )

 

 

 

Exchange Wildcard Certificate imported Powershell without password option (PrivateKeyMissing)

Valid Exchange 2010/2013/2016

Problem:

You can IMPORT a KEYFILE (Password) protected Exchange Certificate via Powershell. The import itself does work, it's there but the Cert is NOT usable for Exchange or visible in Powershell get-exchange certificate or in the Exchange Console under Certificates.

Import-ExchangeCertificate

-Instance <String[]>

[-Confirm]

[-DomainController <Fqdn>]

[-FriendlyName <String>]

[-Password <SecureString>]

[-PrivateKeyExportable <$true | $false>]

[-Server <ServerIdParameter>]

[-WhatIf]

[<CommonParameters>]

 

What you did:

You did use Powershell to import a valid WILDCARD Certificate into Exchange without the password option. If you do this by GUI (Console) you have to enter a password if the Certificate is protected.

  • The new imported wildcard does not open under get-exchangertificate | fl
  • You are UNABLE to remove-exchangecertificate the invalid Certificate with remove-exchangecertificate –thumbprint error: (PrivateKeyMissing)
  • You do NOT see the new Cert under GUI under Server in the Exchange Console

Remove-exchangecertificate -thumbprint E409F4412C605F44296957CD654EE45522EEC481

The certificate with thumbprint E409F4412C605F44296957CD654EE45522EEC481 was found but is not valid for use with Exchange Server (reason: PrivateKeyMissing).

If you TRY to reimport the same Certificate with GUI

e

Already exists

Solution:

OPEN MMC

ADD Certificate Snap in

 

 COMPUTER

LOCAL COMPUTER

PERSONAL CERTIFICATES

 

Be sure that you're using the Certificate Snap-In for the Local Computer account!)

Check IF you find any new Certificates WITHOUT the GOLDEN KEY on the left side in the SYMBOL. These are the imported CERTS where the PRIVATE KEY is missing.

Delete that Certificate if you are sure it's the one you just imported with Exchange Powershell before.

SOLVED – Reimport the Exchange Wildcard Certificate with the CORRECT Options and a KEYFILE (Passwordfile) in Powershell or simply use The Exchange-Console-GUI to import the Wildcard and enter the password there.

 

Please see our important Links regarding handling of Exchange Certificates and Errors

http://www.butsch.ch/post/Exchange-20102013-POP-or-IMAP-with-Wildcard-Certificate-activation.aspx

  • Check that your import the INTERMEDIATE from your CERT provider
  • Make sure your Exchange VLAN Can Reach the Internet and some Certificate Revocations Adress (Here is how to check those etc.)

http://www.butsch.ch/post/The-certificate-is-invalid-for-exchange-server-usage-Exchange-2010-SANUC.aspx

http://www.butsch.ch/post/Generate-SAN-UC-Certificate-SSL-on-Exchange-2010.aspx 

http://www.butsch.ch/post/Exchange-2010-Certificate-stays-in-PENDING-REQUEST-after-import.aspx

Exchange with Wildcard and POP3 / IMAP

http://www.butsch.ch/post/Exchange-20102013-POP-or-IMAP-with-Wildcard-Certificate-activation.aspx

 

 

GPO, W10, CSE_NOBACKGROUND and CSE_Drives GPO, English German mix how to fix RIGHT way

There have been some WRONG Blogs about correcting this issue with wrong GPO / Gruppenrichtlinie Language / Sprach-Files. Here is the error you see.

 

Folgende Fehler sind aufgetreten:

Das Richtlinienpräsentationselement "CSE_NOBACKGROUND" auf das in Präsentation "CSE_Drives" verwiesen wird,

ist nicht vorhanden. Datei \\SERVER045.bsb.local\SysVol\bmw.local\Policies\PolicyDefinitions\GroupPolicyPreferences.admx, Zeile 334, Spalte 70

 

Please do a COPY and DUMP of the Policy Stuff before you change and maybe correct wrong like some people did. In the GPO Console backup the GPO's to disk.

Below you see someone following the three wrong blogs and messing up things.

Delete WRONG ADMX Files in the LANGUAGE Subfolder of the POLICYDEFINTIONS.

Only ADML (Administrative Language Files) are in there. The ADMX file has nothing to lose there in W10/2012/2016 setups.

Now do it the correct way copy over. Sample for English DC and German / Deutsch Client or W10 Admin client. Here is what to copy.

 

We use environment variables to show you. Please adapt these to your domain.

FILE: grouppolicypreferences.adml

SOURCE: %logonserver%\sysvol\%USERDNSDOMAIN%\policies\policydefintions\en-us\

DESTINATION: %logonserver%\sysvol\%USERDNSDOMAIN%\policies\policydefintions\de-de\

Sample is for de-de Germans just adapt to you language short.

 

Reboot the GPO Admin Client or do a gpupdate /force

Error is gone.

 

Exchange 2010 Transport Service down after JULY 2018 Patchday (KB4338818)

 

Certain patches from July 2018 Patchday did render the Transport Service of Exchange 2010 Sp1-Sp3 unresponsive. This can be solved by applying the Patches mentioned in below table. Some of them are "PREVIEW of Monthly" Releases. So Microsoft did not do V2 Patch as before but include the bug fix in the PREWVIEW Cumu.

Most Exchange 2010 DAG we have run on Server 2018 R2 and would be affected. So the important statement is:

 

"For operating systems prior to Windows 2016, the update will be applied as an additional update to the updates released on July 10th. This means you must apply the July 10th update and then may need to execute Windows Update again to receive the additional update to fully resolve the issue. The updates for these operating systems should be fully published to all geographies on Windows Update by end of day July 18th (PDT)."

 

Issue with July Updates for Windows on an Exchange 2010 Server

0

The Exchange team is aware of issues with the Windows Operating System updates published July 10th, 2018 causing Exchange to not function correctly. The Windows servicing team has advised us that they will be releasing updates to the affected packages. We encourage Exchange customers to delay applying the July 10th updates, including the security updates released on the same date, on to an Exchange server until the updated packages are available.

Update: July 17th

We wanted to provide you an update on this issue.

The issue has been resolved and new updates will be available through Windows Update for all operating systems by end of day July 17th (PDT). The Exchange Team recommends that customers use Windows Update or update the catalogs on their own SUS servers to ensure the latest version of the update is available for installation on your Exchange Servers. Doing so will avoid any possible disruption to the MSExchangeTransport service which may have been impacted by the July 10th update.

Update: July 18th

The Windows team has informed us a delay occurred in the release of some packages. Updated packages are now available via the regular release channels: Windows Update, Catalogue, WSUS. These updates should be applied based upon the operating system version you are using with Exchange Server. When using Windows Update to apply an update, you will need to initiate a manual request in the Windows UI to find and download updates.

For Windows 2016, the update will be applied as a replacement to the package delivered on July 10th. Customers running Exchange on Windows Server 2016 should ensure that the latest operating system updates are applied. These updates are available now and can be applied to a production system regardless of previous updates installed.

For operating systems prior to Windows 2016, the update will be applied as an additional update to the updates released on July 10th. This means you must apply the July 10th update and then may need to execute Windows Update again to receive the additional update to fully resolve the issue. The updates for these operating systems should be fully published to all geographies on Windows Update by end of day July 18th (PDT).

The table below outlines the impacted KB for each operating system and the associated KB which must be applied to resolve the issue. In the case where there are multiple updates listed for an operating system, only one of the updates should be required. The presence of two updates is indicative of whether a rollup or individual security update is being used to update the operating system.

Operating System

Impacted Update

Update which must be applied

Windows Server 2016

KB4338814

KB4345418

Windows Server 2012R2

KB4338824

KB4345424

KB4338815

KB4338831

Windows Server 2012

KB4338820

KB4345425

KB4338830

KB4338816

Windows Server 2008R2 SP1

KB4338823

KB4345459

KB4338818

KB4338821

Windows Server 2008

KB4295656

KB4345397

 

The updates in question apply to the operating system and address an issue which causes the Exchange Transport service, responsible for delivering mail, to stop functioning. This condition is unrelated to the .NET changes which were published on the same date. The Exchange team continues to encourage customers to make use of Windows Update or SUS to ensure that the operating systems updates are applied correctly to an Exchange Server.

 

Original links:

https://blogs.technet.microsoft.com/exchange/2018/07/16/issue-with-july-updates-for-windows-on-an-exchange-server/

https://www.reddit.com/r/exchangeserver/comments/8y5qh4/exchange_server_2010_mail_flow_issues_after/

https://support.microsoft.com/en-ie/help/4338818/windows-7-update-kb4338818

 

 

 

McAfee EPO Server SQL Server Performance tips

 

 

McAfee EPO Server SQL Server Performance tips

This is based on McAfee Information for their McAfee EPO DB running under SQL 2005/2008R2/2012 upwards

The EPO Database itself should be:

Autoshrink = False

Auto Close = False

Auto update Statistics = True

 

Auto shrink and auto close are database options that should be set to false. Auto update statistics should be set to true, except for very rare circumstances where the update of statistics is hindering the query performance and there is a customized manner to update statistics on a different interval. See the Performance Optimizer Product Guide for details on how to configure these database options.

 

File auto growth DB Files 256MB, unlimited

File auto growth DB Log files 128MB, unlimited

 

This is just a base recommandation. We learned back with NT4 and RAID Setup that this is important to calculate blocksize. Ask your Storage, VMware people if they still know anything about it. You will be suprised how much they know or not.

 

The file growth settings for the ePO and tempdb databases should be set to auto-grow by 256MB for data files and 128MB for log files. The maximum size should be set to unlimited. It is not recommended to use the auto-grow by percent as it can lead to subsequently larger file growths. See the Performance Optimizer Product Guide for more details.

 

Yes we know, spend CHF 20'000.- for another SSD Raid or shelf and ask your Manager.

Data files and log files should be placed onto separate disks for maximum I/O throughput. See the Performance Optimizer Product Guide for more details.

 

Index and Fragmentation

Indexes with fragmentation greater than 30% should be rebuilt. Fragmentation between 20%-30% requires that the index be reorganized. Optimal index performance is achieved when fragmentation is removed on a regular schedule. See KB67184 and the Performance Optimizer Product Guide for more information.

Review the server task action settings. See the McAfee ePO Product Guide for the chapter on configuring server tasks. If the server task has been provided by a point product, review the guide for that product to ensure that all configuration settings are correct.

Review the scheduled server tasks. If too many server tasks are scheduled to run at the same time, reschedule some for a different time. See the McAfee ePO Product Guide for the chapter on configuring server tasks.

Please see our other McAfee EPO Enterprise PRO Tips

http://www.butsch.ch/post/MCAFEE-EPO-SQL-shrink-large-files-in-small-steps.aspx

http://www.butsch.ch/post/Mcafee-EPO-Server-4X-Database-or-Space-growing-EPOevents.aspx

http://www.butsch.ch/post/Mcafee-EPO-Server-45-Upgrade-to-46-mit-SQL-Express-2005-SP2-to-SP4.aspx

If you need commercial help with McAfee EPO/TIE/DLP/ATD Migration contact us.