Sometimes it’s just best to use command line instead to make the request instead of going through all the troubleshooting involved in making a template visible in certsrv. Use the following command:
certreq.exe -submit -attrib “CertificateTemplate:<nameofyourtemplate>” <pathtocsrfile>
For example, I want to request a certificate from the UCAPPS-Tomcat template I have created, with the CSR WIGL-CCX-PUB-Tomcat.csr located in c:\temp
certreq.exe -submit -attrib “CertificateTemplate:UCAPPS-Tomcat” c:\temp\WIGL-CCX-PUB-Tomcat.csr
Disabled FBA for OWA during troubleshooting. Now I can’t login to ECP, returns HTTP 400.
Run the following two commands to restore to former glory:
Set-OwaVirtualDirectory -Identity “<exchange server>\owa (Default Web Site)” -FormsAuthentication $true
Set-EcpVirtualDirectory -Identity “<Exchange Server>\ecp (Default Web site)” -FormsAuthentication:$True
After installing Windows Admin Center and specifying HTTPS (specifying thumbprint of your internally issued certificate) and a customized port you get this error when you attempt to connect to your server:
The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accept requests.
Just run this command:
winrm quickconfig -transport:https
Pretty descriptive error message don’t you think? This could mean a multitude of things but for me the Identity provider certificate hash was incorrect, I forgot to tack on a couple of == after I crossed reference the XML file from
Because of Covid-19 I had to stand up a large RDS farm to accomodate over 800+ users for a customer. Users already have pre-existing folder redirection enforced via Group Policy since the XP days. So I ported the settings from pre-existing GPOs to a new GPO for my session hosts.
Everything seems to be working great, for new users. But for pre-existing customers, their Document folder specifically refuses to re-direct and would point to their local profile no matter what. There were two principal problems.
- By default, folder redirection points to \\server\share\%username%\documents. This may be a problem because legacy users will need to point to \\server\share\%username%\My Documents. For this you have to check this below:
2. We’ve noticed for some users it would map to the right folder but in explorer it would still save “no items found.” By default, “Grant the user exclusive rights to Documents” is enabled. You have to disable it before legacy users can see their Documents visible in File Explorer
If you’re reading this you’ve probably heard of Windows Autopilot / Modern Desktop being thrown around like confetti by Microsoft and their VARs. They have gone so far as to declare Autopilot as being the ultimate solution while dismissing SCCM / OSD (Operating Systems Deployment) as being relics slated for extinction like the dinosaurs. So as an independent consultant whose core practice evolves around SCCM and desktop automation, I’m naturally skeptical. But as a matter of professional curiosity, I have a vested interest in this technology and have serviced several progressive customers who have bought into this model.
Does Autopilot sound awesome in theory? Absolutely. Does it have the legs to supplant SCCM/OSD? Doubtful… at least not now anyways, or unless your end-user compute requirements are so basic ,much of the caveats don’t apply to you. This is not just my opinion, at Ignite 2019 Microsoft announced Endpoint Manager (co-management using both SCCM and Intune) which seems to be a step backwards.
Here are some of the reasons why I consider Autopilot to be impractical for most organizations:
- Users don’t want to have to wait for hours before they can start using their PCs (this is assuming they need more than just Office). Not every user has gig Internet, bandwidth we are accustomed to in LAN environments
- Speaking from prior experience (could of improved by now) deploying Win32 apps through Intune is unreliable. Logging and reporting is sketchy for those looking to troubleshoot. Your best bet is to put the app inside a wrapper with better logging
- Most enterprises have sizable investments in on-prem solutions, their needs are more complex than just Office 365 or SaaS solutions
- Not every customers want to Azure AD join their endpoints
- Most mature organizations already have made investments in other 3rd party MDM solutions
- Drivers and firmware get out of date. If you have to do a wipe and load you have to account for this shortfall
- Many features in Intune are still in preview mode, which speaks to its immaturity. When you work with this stuff, you just get a sense of its rawness
There are more.. but I’m just trying to get the point across to support the subject line.
SCCM is not going away soon. For those who have invested heavily in this technology, they should continue to utilize it to the fullest and maybe consider the adoption of Intune to compliment management outside the perimeter.
For that, I would recommend using Azure Hybrid AD Join, SCCM and Intune for co-management. I will release a series of blogs on how to set this up, but more from the vantage point of customers who are deeply vested in SCCM, on-prem AD and looking to extend management to Intune just to round things out.
This happens when you run the Invoke-MbamClientDeployment.ps1 PowerShell script say within a Task Sequence.
To bypass this issue you have to comment out the following in the script:
This will essentially not conduct MBAM policy check and go proceed with encryption.
Unlike SCCM, MDT does not have a “pre-start” field when you create a boot image. The ask is for MDT to scrub the primary disk before attempting to load the list of task sequence(s). Doing so is useful because sometimes a machine in a dirty state will kill the MDT from initializing and reboot prematurely.
Multiple things you have to do to achieve this:
- Alter the C:\Program Files\Microsoft Deployment Toolkit\Templates\Unattend_PE_x64.xml file:
2. Create an “Extra Folder” to contain the necessary scripts to do this. In my case I created a folder call D:\SRVAPPS\CMTRACE
3. The cleandisk.txt would look like this:
4. While the cleandisk.vbs would look like this:
5. Go to your Workbench Properties and go to Windows PE tab. Add your Extra Folder created in Step 2 into the field as outlined below:
6. Update your Deployment Share. IT IS IMPORTANT, that you select “Completely Regenerate the Boot Image”
7. Optionally update the Boot Image on the WDS service (if you have it) and restart the service.
There you have it. When you PXE boot into WINPE and press F8 you will see all those files in the Root of X: and it should call the scrub disk VBS script before calling LiteTouch.vbs.
Just to note I originally tried just calling it with CMD.EXE, but it just kept an command prompt window open. I advise using VBS for this.