The mis-spelling above is intentional BTW, this is how it appears in the SMSTSLOG.log file. Typically a task sequence will be ticking along then something will happen after which the above error is displayed, almost always when it is trying to install either a ConfigMgr package or a ConfigMgr application (ie not a command-line). This is because the client isn’t actually required to execute, for example, a Powershell command line, but it must be initiated if a package or application is called on.
Ultimately, in my experience, this always comes down to one issue – an inability to reach the Management Point. There maybe various reasons for this and one such reason is described here.
However in my case this wasn’t the problem. Following a task sequence upgrade to 1909, I found all our laptops failing with this same error. These laptops were all on the internal network (ie not connected via VPN/DA, etc). If I logged on locally, I found that while I was able to ping machines, I was unable to reach shares from other machines on the network. Something was very wrong with networking (and obviously why the build was failing).
Running an IPCONFIG /all revealed that the broken laptops were all trying to use the IP/HTTPS Tunnel Adapter Interface. This synthetic interface is typically used for Direct Access which these laptops were certainly not using at the time. On further investigation, if I removed the group policies the laptops inherited for the duration of the upgrade I was then able to complete the upgrade without issue.
The group policies are causing the tunnel adaptor to become active albeit briefly (haven’t got to the bottom of why this happens BTW). Unfortunately the adaptor isn’t able to communicate with the MP as it should. Then I read an article about a bug found in the 1909/2004 OS’s. You must ensure this patch (Oct 2020 update) is applied to the installation media prior to upgrade. Essentially, the certificates were disappearing causing the communication problem with the Tunnel adaptors on the laptop models. Once the patch was added, all was well.
I’ve been meaning to do a quick blog about this issue for some time now especially as I have witnessed this incredibly frustrating problem at two separate clients during roll-outs, particularly OS deployments that also require updated applications, etc. A Google search will reveal many different ‘fixes’ for this issue, most common of which tends to involve re-installing the ConfigMgr client. Indeed this is an approach I took first time round and usually seemed to work but it isn’t really a fix as such.
In the latest instalment, this approach just didn’t work at all so I needed to find what else was causing the issue. If I left the offending application to time out – this might take several hours btw – I could usually restart it and it would go ahead and download. However this was still unacceptable.
Turns out the answer, with hindsight, was the same in both instances – too many policies. Essentially in both circumstances, the machines experiencing the issue had a lot of applications and/or task sequences deployed to them. Task sequences in particular usually have many steps and this seems to flood the client causing it to display this ‘stuck at 0%’ behaviour. Try removing the machine from all unnecessary collections, leave for an hour or so for the machine to expunge any of the old deployments and try again.
This still feels like a Microsoft issue to me but until it’s addressed this is the workaround.
I recently had this while uploading thousands of photographs to my ODfB account. Essentially, you’ll set it syncing (perhaps overnight) and then come to it in the morning and you’re presented with the error message, “OneDrive can’t sync now, please try again later”.
I tried resetting the app (onedrive.exe /reset), re-starting, reinstalling, nothing worked. Turns out, there is a limit to how much data you can upload per day.
The setting you want lives in the ClientPolicy.ini :
For ‘standard’ (personal) OneDrive, go to: C:\Users\<username>\AppData\Local\Microsoft\OneDrive\settings\Personal\ClientPolicy.ini.
For OneDrive For Business (ODfB) OneDrive, go to: C:\Users\<username>\AppData\Local\Microsoft\OneDrive\settings\Business1\ClientPolicy.ini.
Please note, depending on your OneDrive setup and number of accounts, the Personal/Business folder name may change.
Open the ini file in notepad and change MaxClientMBTransferredPerDay from its current value to something higher. I found that I needed to change this value to 50000000 in my case. It appears that simply setting it to ‘0’ doesn’t work for infinite, either.
One other observation: occasionally, I noticed OneDrive would appear to change this value back to what it was and fail again. Just repeat the procedure above and it will carry on.
I don’t know quite how widespread this issue is but it’s something I have had some trouble with on and off since I updated my OS to Server 2019 last year. That said, I’m not saying this is an issue limited to this OS; indeed I have seen it on other OS’s too.
The issue is this : Word will ask you to sign in and after entering your email address, it will freeze for 5 minutes before returning you to the (unlicensed) state you were previously in. Similar with Outlook – you enter your email address and the white password box appears but appear blank and freezes for 5 mins before returning you to the previous (unlicensed) state.
There are a number of things that you might try (including full uninstall/reinstall in desperate cases) but I’ll show you a couple of things you should try before doing this (or calling Microsoft, as they will ask you to do this too, more likely than not).
First – Remove previous license information
Open C:\Program Files\Microsoft Office\Office16
From a cmd prompt, type cscript .\OSPP.VBS /dstatus
This will give you a list of previous license keys used. Remove all these using cscript ospp.vbs /unpkey:<5 digit code>
Second – (if the above doesn’t work) Disable Modern Authentication.
Open up regedit and navigate to the following key:
Exception: System.ArgumentNullException: Value cannot be null. Parameter name: objectID at Microsoft.ConfigurationManager.PhasedDeployment.Application.Deploy(IDatabaseOperation databaseOperation, List`1 phases, String phasedDeploymentID, String objectID) at Microsoft.ConfigurationManager.PhasedDeployment.PODRuleEngine.EvaluatePhasedDeployments(SqlConnection connection)
I was testing a phased deployment the other day and couldn’t get it to work for the life of me. Although the phased deployment appeared under the Phased Deployments tab for the Office 365 application I was targeting, a corresponding deployment didn’t appear for the phase 1 collection under the Deployments tab.
I took a look at the SMS_PhasedDeployments.log on the site server and all I could see was the error message above. I would also see it repeat about every 2 minutes as below.
It kept mentioning there were two phased deployments it was trying to evaluate, but there were no other phased deployments set. There is a well-known bug when a task sequence can get locked and the admin will typically go into the db and remove the offending ID locking the task sequence from the database. Well it turns out this is a similar issue with an equally similar solution.
Go into the ConfigMgr (sorry, Endpoint Manager!) DB and find dbo.PhasedDeployment, right-click the table and click Select Top 1000 rows.
Identify the offending Phased Deployment from the list and copy the PhasedDeploymentID.
Click New Query from the toolbar and type:
DELETE FROM dbo.PhasedDeployment WHERE PhasedDeploymentID='<PhasedDeploymentID>'
I would be inclined to delete and recreate your original phased deployment (from the console!) to be sure of a clean deployment but technically you be good from here on.
I recently decided to completely overhaul my email and passwords to all major sites after getting tired of the relentless spam I received to the account I have had for the past 20 years or so. Additionally my email and (admittedly very old) passwords showed up on Have I Been Pwned? so I thought it was time for a clean break. This is no small undertaking as you can probably imagine but the first step is to sort out your email account. Most importantly though, you still need to be able to receive email to your old address and in some cases, still be able to send from the old account.
Of course you can just add your old address as a secondary email account so you still receive email to that address but I wanted to use the old account as a filter to the hundreds of sites who insist on sending me crap every day which I don’t especially want to read.
Anyway, in my case, I want to create a new email address (mailbox) as a primary address and have a secondary mailbox for my old email address plus another for my business email address. I also wanted to be able to send from these accounts as though they were my primary email if I wanted to. Please note, by secondary mailbox, I am in effect talking about a shared mailbox for which you will have exclusive access to receive and send mail. A secondary mailbox requires no further licence.
IMPORTANT: Backup your current inbox to a PST file. You can do this by selecting File | Options | Advanced | Export button | Export to a file | Next | Outlook Data File (pst). Ensure you select the correct Inbox from here and click Next. Enter a path for the PST file and click Finish.
In the Microsoft 365 admin center go to Settings > Domain. Ensure the new domain you need is in a healthy state. If not, click on the domain and follow the instructions to make sure it is healthy before proceeding further.
Open up the Exchange admin center and go to dashboard | recipients | shared. Click the ‘+ ‘ sign as below
This will open up the New shared mailbox dialogue. Add your name and your NEW email here. Click the + sign at the bottom and add yourself as a user with permission on the mailbox
Go to dashboard | recipients | mailboxes and select Convert to shared mailbox on the right hand pane.
Click on the shared heading at the top to return to the list of shared mailboxes. Select your NEW mailbox and select Convert to regular mailbox on the right pane.
Open the shared mailbox(es) dialogue by double-clicking on it/them. Click email address. Ensure your new email address doesn’t appear in the list here. The mail address under SMTP is your default address for that mailbox.
Click mailboxes in the toolbar at the top and ensure your new email address is listed there. Sometimes there is a short wait for the mailbox to appear.
Ensure Outlook is closed. Open the mail applet in Control Panel and add your new email address here. After it has resolved and appears in the applet, click Set as Default. I found that I had to actually remove the old email account and re-add it but you may have a different experience here.
Open Outlook and you should see your new account. Click File | Add Account and add your (now secondary) mailboxes to Outlook. Assuming you have given these appropriate permissions in Exchange admin center, you should now be able to add the address of this/these extra shared mailbox(es) in the From field of Outlook and send as that account if you wish. You new account should now default. To be sure you can go back to Microsoft 365 admin center | Settings | Domains and ensure your preferred new email account is set as default there if it isn’t already.
Just a really short post on an issue I saw a little while back which I’ve been meaning to get round to documenting.
Whilst working on VM optimization project, I booted up one of my VMs for testing and received the above message during the OOBE stage. The reason for this is because I disabled one of the scheduled tasks which I thought looked fairly innocuous, CloudExperienceHost. Turns out this is important to leave enabled, even if you don’t want your VMs connecting to the cloud as the Out of Box Experience uses it. Specifically, the task can be found under:
Arguably there are newer and more fancy ways to do this in recent iterations of SCCM. If you wish to set up a standard internet facing SCCM environment or just an SSL secured environment this is the old skool way.
CREATE SCCM CERTIFICATES
Open CA | Right-Click Cert Templates > Manage
Right-Click Web Server template > Duplicate template
Open new duplicate template :
a Request Handling tab: Check ‘Allow private key to be exported’
b General tab : Change name to “ConfigMgr IIS Cert”, validity 5 years
c Subject name : default (‘supply in the request’ should be checked)
d Security tab : remove the ‘Enroll’ permission from Domain Admins and Enterprise Admins, add your SCCM_Site_Servers group and add Enroll and read permission to this group | Click OK
Open new duplicate template :
a Compatibility tab: keep defaults (ensure Windows Server 2003)
b General tab : Change name to “ConfigMgr DP Cert”, validity 5 years
c Security tab : Add your SCCM_Site_Servers group and add Enroll and read permission to this group | Click OK
Open new duplicate template :
a Compatibility tab: keep defaults (ensure Windows Server 2003)
b General tab : Change name to “ConfigMgr Client Cert”, validity 5 years
c Security tab : Click ‘Domain Computers’ group and add AutoEnroll and read permission to this group (don’t uncheck ‘enroll’) | Click OK
Open CA | Right-Click Cert Templates > New > Certificate Template to issue
Select the three new certs from the ‘Enable Certificate Templates’ box. | Click OK
Open the GPMC, open default domain policy (or wherever you have your PKI policy)
a Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
b Open up ‘Certificate Services Client – Auto-Enrollment’. Change ‘Configuration Model’ to ‘Enabled’
c Check ‘Renew expired certs…’ and ‘Update certificates that use cert templates’
ADD CERTS TO SCCM
On the DP open the certificate MMC > Computer > Personal > Certificates | Right-click folder > All Tasks > Request New Certificate
Next > Next | On ‘Request Certificates’ page check ‘ConfigMgr DP Cert’ and click ENROLL > Finish
While still in the certs MMC, Right-click the DP cert you have just imported > All Tasks > Export > Next. Select Yes, export private key
Keep defaults on Personal Information Exchange – PKCS #12 (.PFX) and click next.
Enter a password > Next > Save the file as C:\Temp\SCCM_DP_Cert. Click finish
On the MP open the certificate MMC > Computer > Personal > Certificates | Right-click folder > All Tasks > Request New Certificate
Next > Next | On ‘Request Certificates’ page check ‘ConfigMgr IIS Cert’ and click ‘moe information is needed…’ link
Under Subject Name, select ‘Common Name’ and add the name of the server, eg SCCMMP01 > Add
9.Under Alternative Name, select DNS and add the FQDN of the server > Add
Under the GENERAL tab, add the name of the server as the friendly name
Under the Cert Authority tab, select your CA if it’s not already selected. Select Enroll > Finish.
On the MP (internet facing if there is one) open IIS > Default Web Site > Bindings… | Edit HTTPS
Select the new SSL certificate. If you don’t see HTTPS, click add and create it.
Repeat the above on any other MPs
From the SCCM console go to Admin\Overview\Site Configuration\Sites | Properties > Client Computer Communication. Add the Root CA Certificate you created earlier.
FINALLY!!!! Go to Admin\Overview\Distribution Points | Properties and add the certificate and password you created on the DP in point #5. Rinse and repeat for all your DPs.
Just select YES if you get a message about it being a copy of one used on another DP.
To add certs for the SUP/WSUS see https://www.petervanderwoude.nl/post/how-to-configure-a-software-update-point-to-use-ssl-for-communicating-with-wsus/
I have just had to
do this so I thought I’d make the most of the ordeal by documenting. I make no
apologies here – I am giving you the bare minimum click-by-click. I’m not
attempting to tell you what you’re doing along the way as this post will just
be too long. As long as you do everything as indicated and don’t take any
shortcuts, you should be fine. If you previously had a CA in place, I recommend
you fully uninstall them before starting.
You will need two
VMs, one domain joined (IssuingCA) and the other just in a workgroup (RootCA).
In my example below, my rootCA is SVR-CA-01.bondynet.org and my Issuing CA is
SVR-CA-02.bondynet.org. These names make up some of the cert names in the instructions
below so please ensure you substitute as appropriate for your environment. One
final caveat : this was put together on Windows 2012 R2 so there maybe one or
two minor changes to the interface in places but honestly not much has changed
Workgroup computer, Install cert services
Go thru config wizard, Select: a Cert Authority b Standalone CA c Root CA d New private key e All default crypto options f Default names g Default Validity (5 years) h Default db locations i Click CONFIGURE
Open Cert Authority > Properties > Extensions > CRL Distribution Point (CDP) a Click Add.. and under location type : http://svr-ca-02.bondynet.org/CertData/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl (replace with your issuing CA) b Check Include in CRLs… c Check Include in CDP extension… d Select AIA from cbobox > Add AIA e http://svr-ca-02.bondynet.org/CertData/<ServerDNSName>_<CaName><CertificateName>.crt (note the crt extension and the underscores for AIA). f Check ‘Include in the AIA extension…’ g Restart services when prompted.
Publish CRL by going to Revoked certificates node | right click > all tasks > Publish
crl and crt published at C:\Windows\system32\CertSrv\CertEnroll. Copy this path to clipboard.
ROOTCA properties > General > View Certificate #0 > Details > Copy to file > Next DER Encoded > Next > save as C:\Windows\system32\CertSrv\CertEnroll\RootCACert.cer
Browse to \IssuingCA\C$\Temp\Certs and drop the three certs in the folder
PUBLISH ROOT CA IN AD
Open the GPMC, open default
domain policy (or some other if preferred)
a Windows Settings > Security Settings > Public Key Policies
> Trusted Root Certification Authorities
b Right-click > Import > Next > browse to \IssuingCA\C$\Temp\Certs\RootCACert.cer
> Next > Finish
Run GPUpdate /force and you
should see your new certificate appear under ‘Trusted Root Cert
Authorities’ in Certificate manager MMC.
Install Certificate Authority with all Role Services
Once complete, in SVRMGR click the yellow triangle for post config.
Specify creds or leave default | Next
Select Cert Auth, Cert Auth Web Enrollment | Next
Select Enterprise | Next
Subordinate CA | Next
Create a new private key | Next
All default crypto options | Next
All default names | Next
Default req filename and location (C:\SVR-CA-02.BONDYNET.org_BONDYNET-SVR-CA-02-CA-2.req) | Next
Default db location | Next | Configure | OK. Don’t configure additional roles when prompted for our purposes here.
REQUEST CERT FROM PARENT CA
On the root CA, browse to \\IssuingCA\C$ and copy c:\SVR-CA-02.BONDYNET.org_BONDYNET-SVR-CA-02-CA-2.req locally.
In CA MMC console > | Right click > All Tasks > Submit New Request > Select SVR-CA-02.BONDYNET.org_BONDYNET-SVR-CA-02-CA-2.req > OK
Go to Pending Node to see the new certificate. Right-click > All Tasks > Issue
Under ‘Issued Certificates’ node, right-click > Open > Details tab > Copy to file > Next
Select Cryptographic Message Syntax Std (.P7b) and select ‘Include all certs in path’. | Next
Open Browse and you should be in the CertEnroll directory. Call the cert ‘IssuingCACert’ | Next | Finish | OK | OK
Copy the new .p7b certificate to the \IssuingCA\C$\Temp\Certs\ location.
INSTALL & CONFIGURE CERT ON ISSUING CA
Create a new folder at C:\inetpub\wwwroot\CertData
Copy the .crt file and the .crl file from C:\Temp\Certs to C:\inetpub\wwwroot\CertData
Open the CA console on the Issuing CA. Right-click servername > All Tasks > Install CA Certificate. Select The new p7b certificate.
The business of adding a front end for a PXE-driven SCCM OS build is generally a pretty important consideration if you want to specify some basic information prior to deployment. It’s also something that I’ve felt has never been properly addressed by the SCCM development team. To be fair you could argue it’s not their job to do this but with more functionality being adding to every single aspect of SCCM in every new release, it does feel like something that probably should be looked at in the future.
For now, there are plenty of examples of great front ends on the internet – look up ‘Pretty Good FrontEnd’ by Johan Arwidmark or ‘Pretty Good Front End Clone’ by Maik Koster. These two have been around donkey’s years. One of my favourites is Nicolaj Andersen’s very neat ConfigMgr Front End which offers a whole world of features. Additional infrastructure is necessary to accommodate this however, in the form of web services.
So why create another? Well I’m certainly not pretending to set the world alight with some kind of ingenious new approach but I always felt there was just a little too much fiddling about with most of the solutions I saw elsewhere. What I wanted was something I could ideally just drop straight into my WinPE image which would just work. There are certainly features I could add (and may indeed do so if enough people ask) such as ability to remove certain sections, eg, domain, OS, etc. However in an effort to keep things simple I have left this for now.
The Front End
This is a typical illustration of what it looks like in my lab. Most aspects are configurable via a small ini file (yes I know it’s a bit 90’s but let’s face it, it’s a damn sight easier to use than an xml file for this kind of thing). The ini file below is configurable for the OUs in your environment, the domain (or domains) and even colour and font size. One area I went a little off the beaten track is the ability to select different images you want to use in your task sequence. This is great in my lab as I often want to test stuff out on different OS’s and will routinely add a new image when necessary to my tried and trusted task sequence. As such I’ll detail this a little more.
If you want to use the same task sequence but have different images available in that sequence, you can enter them in the ini file. Just be sure to enter the appropriate option/filter in appropriate task sequence step. For example, in the image above we have a number of different OS’s which relate to separate images. Under the INSTALL section of your task sequence you might have one or more separate steps to Install Windows 10, Install Server 2016, etc. On each of these steps, click Options and add a Task Sequence Variable condition, eg:
TS VARIABLE: OSDImageEquals <Windows 10 1803>
It is important that the text in the OS box above equals the OSDImage value of your condition.
Of course, you can just add a description in the Config.ini file instead and have one image step in your task sequence with no condition set and all will be well. I suspect this is what most people will want. The option to do it this way is just there if you want it.
Typical Config.ini settings below. This file must always exist in the exact same folder as the NewFrontEnd.exe executable.
:: [ORG_UNIT] - Enter all OUs you want displayed in format OU=Dept, OU=Org, DC=domain, DC=suffix one after the other.
:: [DOMAIN] - In most cases, this is more for show but can be used to build a workgroup machine too if WORKGROUP is specified underneath the primary domain.
:: [OS] - If your task sequence can build more than one image, add it here, eg Windows 10 1607 LTSB. Then add a task sequence variable condition called OSDIMAGE and equal it to the image name in your TS.
:: LOGO, recommended max size is approx W:120, H:120 for a font size of 8-10
:: BACKGROUND, Enter standard OS colour names, eg Red, DarkRed, Marroon, MidnightBlue, etc
:: FONTSIZE, recommend, 8-10 but it will go bigger. Seems to jump in 2s, eg, 8,10,12, etc. This has a bearing on the size of the form.
:: FONTCOLOR (American spelling, sorry) see BACKGROUND, above.
:: SMSTSPREFERREDADVERTID, If specified, enter the Deployment ID of the task sequence you want to run. This will override any other advertised task sequence either 'available' or 'required' and the wizard won't show.
:: HIRESDISPLAY, If HIRESDISPLAY=True the size of the form is increased so it doesn't get 'scrunched up' on the display. This has been tested against a Surface Pro 4.
:: NOTE - [ORG_UNIT], [DOMAIN] and [OS] should all have at least one value (ideally) so the interface has something to show. Settings under [MISC] can be removed or ignored by adding a semicolon before the setting.
Windows 10 1803
Windows 10 1607
Windows Server 2016
Windows 2012 R2
Windows 10 1607 LTSB
Windows Server 2008
So how do you get this working in WinPE?
Create a share somewhere and drop NewFrontEnd.exe, Config.ini and your company logo png into it (and/or possibly RunFEUI.vbs – see end of post)
In SCCM go to your chosen boot image, right-click | properties | Optional Components. Select Microsoft .NET (WinPE-NetFx). This is a C# application so it needs this option available in your boot image binaries.
Select the Customisation tab. Under Prestart Command Settings enter “X:\sms\PKG\SMS10000\NewFrontEnd.exe”
Select Include files for the prestart command
Select the share you created above with the files in for the source directory.
If you want to, add a background, click OK and you’re done. After the update distribution points wizard has completed, double check the Last Update information in the bottom section of the SCCM console to ensure the time matches the time you ran the wizard and everything has updated as it should. This is important as it hasn’t usually finished updating just because the wizard progress bar has completed.
For The Adventurous.
One of the neat things about using the above method is that there is no ugly command prompt in the background as it brings up the front end interface. However the downside of this is that all the files are inside your WinPE image so if you want to update them you have to go through the above process once again which is both time consuming and laborious. One solution though is to simply point to a script that will map a drive to a share that exists elsewhere on your network and execute the files from there instead. This facilitates updating the files on the fly.
In the zip file included below, there is a file called RunFEUI.vbs. Simply open it and edit it to fit your environment (ie edit line 4 with the appropriate drive mapping and account).