You are browsing the archive for Known Issue.

How to replace expired certificates on ADFS 3.0 the right way

1:44 pm in 2012R2, ADFS, ADFS 3.0, BYOD, certificates, Cloud, Enterprise Mobility Suite, Global Managed Service Account, IIS, Known Issue, Lab, Power Management, WAP, Web Application Proxy by Kenny Buntinx [MVP]

 

As with all IT equipment that is using certificates for enhanced security, there will be a time when the certificates expire and it will need to be replaced. Below you will find the procedure for ADFS 3.0 and the Web Application Proxy:

First step is to create a new CSR on one of you’re servers and request a renewal of the existing certificate ( in our case a *.demolabs.be) . After the request has been processed , download your certificate and import the certificate on the server where you created the CRS earlier. For ADFS / WAP it is very important you will have the private key exported with the certificate. You can only export the certificate with a private key on the sever where you previously created the CSR .Export with private keys to *.pfx and import on WAP + ADFS

If you do not do it as described above with and export of the private keys , you will face issues even if you did it exactly as described below as shown in the screenshot below :

image

 

Follow the procedure below , starting with the ADFS server:

  1. Log onto the ADFS server.
  2. Import the new (exported with private key) certificate to the server. Make sure this is added to the personal certificate store for the computer account.
  3. Find your thumbprint for the new certificate. Either use the GUI thru the MMC to see the details of the certificate or us powershell with Run Get-AdfsSslCertificate.. Take a copy of the thumbprint and ensure that the spaces are removed.
  4. Make sure that the service account that is running the ‘Active Directory Federation Services’ service is granted read access to the private key.
  5. Launch AD FS Management, expand ‘Service’ within the left pane and click ‘Certificates’ , then click ‘Set Service Communications Certificate

image

 

  1. Restart the ADFS services. However this is not enough. Changes made in  the GUI does not change the configuration based on the HTTP.sys. To complete the configuration change, run the following PowerShell command : Set-AdfsSslCertificate –Thumbprint <Thumbprintofyourcertificate>.
  2. Make sure to restart the server

Now you need to log onto the WAP server.

  1. Import the new (exported with private key) certificate to the server as in step 1. 
  2. Run the PowerShell commando for changing the certificate: Set-WebApplicationProxySslCedrtificate –Thumbprint <Thumbprintofyourcertificate>
  3. All of your publishing rules defined in the WAP need to be updated with the thumbprint of the new certificate. Use Powershell for  updating them with the new thumbprint. Run: Get-WebApplicationProxyApplication –Name “WebAppPublishingRuleName” | Set-WebApplicationProxyApplication –ExternalCertificateThumbprint “<Thumbprintofyourcertificate>”
  4. Restart the Web Application Proxy services to complete the configuration

Now you are done and you are a happy admin once more . Took me some time to figure it out .

Hope it Helps ,

Kenny Buntinx

MVP Enterprise Client Management

SCCM OSD Deployment : The IIS Admin service is not starting anymore on a deployed sysprepped Windows Embedded 2009 with IIS 6.0 installed

12:44 pm in ConfigMgr, ConfigMgr 2007, ConfigMgr 2007 R2, ConfigMgr SP2, configmgr2007, IIS, Installation, Known Issue, OSD, sccm, SCCM 2007, SCCM 2007 R2, SCCM 2007 SP2, sccm2007, script, WES, WES 2009, WES2009, XPe by Kenny Buntinx [MVP]

Lately I have been busy with testing & deploying for a big project some Windows Embedded 2009 devices , called the Advantech ARK –1388 .One requirement from the customer was to have IIS 6.0 installed.We decided to include the IIS 6.0 component into the WES 2009 image with Target builder  ( witch is a tool for building the WES image ), but every time we deployed an image after it had been sysprepped with SCCM, the IIS Admin service would fail to start .

Because this needed to be deployed onto three thousand (3000) WES devices , we contacted Microsoft PSS support for some help. Below you will find our findings and workaround for the issue .

Our problem :

We installed a Windows Embedded 2009 image with IIS 6.0 on a Advantech ARK-1388 and it is running fine.The OS is prepared for system cloning using the sysprep.exe tool ( supported since WES 2009 ).

When we reapplied the master image  with SCCM R2 SP2 and mini-setup was completed, the OS seems to run fine, however the "IIS Admin" service does not start and returns the following error:
"Windows could not start the IIS Admin on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code -2146893818."

There are no related errors in the Event Logs. IIS cannot be repair-installed using the Add/Remove Programs component of the Control panel.( this was done to see if we could automate a self –repair )

We would like to deploy the WES image using the OSD feature of SCCM 2007 R2 ,but the problem also occurs when customer calls sysprep.exe manually without the usage of SCCM. ( that’s what we thought , SCCM always works great !! :-) )

 

Our environment :

We have a Windows Embedded 2009 image with IIS 6.0
We have a SCCM 2007 R2 SP2 environment

 

The summary of our troubleshooting :

1. Microsoft CSS discussed with the WES and SCCM teams if WES2009 is supported on SCCM 2007 R2. After a discussion they have modified there statement on the web , see http://blogs.technet.com/configmgrteam/archive/2010/01/25/things-you-need-to-know-when-using-windows-embedded-standard-2009.aspx

2. the proposed workarounds from Microsoft (re-installing MSDTC and IIS) from the " WES Resource Kit" didn’t solve the problem.

3. We checked the FBWF status on the sysprepped image. It was still disabled as it should .

4. Microsoft spoke with the IIS team about the issue. Discussion results:
  a) It’s a known problem that IIS doesn’t work after sysprepping the image because of the changes made by sysprep.
  b) Using sysprep on XP Pro is not supported, see KB326779 "Supported IIS configurations for use with Sysprep"
  c) The only supported solution is to install IIS after the sysprep phase. On XP Pro PCs you can run an unattended IIS installation
     using the Sysocmgr command (which can add or remove Windows Components). E.g. as described in
     KB309506 "How To Perform an Unattended Installation of IIS 6.0"
     Here is the catch !! : Unfortunately Sysocmgr.exe is not shipped with the XPe database ===> meaning that it is impossible to install IIS 6.0 after we have deployed our WES 2009 client !

5. As discussed with Microsoft and the IIS team I tried to "repair" the IIS Admin service after the final sysprep boot by using SysOCmgr.We have copied the missing sysocmgr.exe from an XP Pro SP3 PC and I’ve had to insert an XP Pro SP3 CD into the CD drive for the missing files.We don’t believe this workaround can be used by my customer (legal and technical issues).

6. For a test we have used fbreseal instead of sysprep. The IIS Admin service was running after fbreseal.But as I know deployment via SCCM 2007 OSD requires the usage of sysprep and fbreseal cannot be used in this scenario.

 

Our Solution :

Together with the WES product team & Microsoft PSS support we found an easy workaround to get the "IIS Admin" service running again on the sysprepped WES 2009 image.
The workaround switched off the IIS components in the registry and called the FBAOC.exe tool to re-install IIS.It solved the problem on our test devices.

Here’re the details about this workaround:

1. It doesn’t need the XP Pro SP3 CD.
2. It doesn’t need any file from an XP Pro SP3 PC (like sysocmgr.exe).
3. It doesn’t need to collect any IIS files into a special installation location.

The workaround is just:

1. Uses your original SLX file and WES 2009 image which uses the FBOCMgr phase 5550 for the IIS components.
   It means you can run the workaround on your original sysprep-ed images.
2. Changes some IIS registry settings used by the OS to install IIS.
3. Uses a WES-specific command (FBAOC.exe) which is part of your original SLX file and image.
4. Step 2-3 can be executed by the attached files:

  a) MyIIS-Off.reg      for changing the registry

*********************************CODE BEGIN**********************************

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OC Manager\Subcomponents]
"iis_common"=dword:00000000
"iis_inetmgr"=dword:00000000
"iis_www"=dword:00000000
"iis_www_vdir_scripts"=dword:00000000
"iis_www_vdir_printers"=dword:00000000
"iis_doc"=dword:00000000
"iis_ftp"=dword:00000000

*********************************CODE ENDS**********************************


  b) MyIISinstall.bat   runs the workaround (by using MyIIS-Off.reg)

*********************************CODE BEGIN**********************************

@echo off

echo Changing registry settings…
regedt32 /s \MyIIS-Off.reg

echo Enabling IIS features…
\windows\FBA\FBAoc.exe

echo Done.

*********************************CODE ENDS**********************************

Pls. put the files in the C:\ root folder on your sysprep-ed WES 2009 image and call the MyIISinstall.bat file from a command line.

When running properly the batch file will run for 1-2 minutes and it’ll display 3 output lines:
        Changing registry settings…
        Enabling IIS features…
        Done.

Afterwards the "IIS Admin" service should be running.

So this scenario is not supported on XP Pro. But this workaround is supported.
This is a known problem/limitation on XP Pro. The same problem occurs on WES installations because WES uses exact the same XP Pro binaries.

 

Hope it Helps ,

 

Kenny Buntinx

SCCM 2007 R2 – SQL Reporting services, Named instances and greyed out config option

10:52 am in ConfigMgr 2007, ConfigMgr 2007 R2, Known Issue, Reporting, SCCM 2007, SCCM 2007 R2, SQL Reporting services, SRS by Kenny Buntinx [MVP]

Hi All,

 

ConfigMgr 2007 R2 introduced a new feature for reporting. SQL reporting services based reporting instead of the original web based reports was added as a new feature. This makes sure that all system center products now use a consistent reporting product. Although both reporting methods can be used in conjunction with each other in the current release, as previously mentioned on this blog, this will not be the case in Sccm v.Next.

In this respect it makes sense to learn the ropes on this SRS technology now, one of the issues I have seen reporting, and which I ran into myself, is a greyed out admin ui interface if you try to start using the ConfigMGr 2007 R2 reporting services feature. After reporting the issue, the ConfigMgr team figured out what the issue was and they updated question 6 on their SRS faq:

http://blogs.technet.com/configmgrteam/archive/2009/05/14/faq-sql-reporting-services-integration-with-system-center-configuration-manager-2007-r2.aspx

For those of you who already have installed SRS, and want to use it in a named instance, you should be able to add another SRS default instance to the same box, and this should clear up the greyed out configuration options in the admin ui when you try to use the “copy reports to reporting services” wizard, or when you try to configure the properties of your ConfigMgr reporting services point in reports \ reporting services

Enjoy.

“Everyone is an expert at something”
Kim Oppalfens – Sms Expert for lack of any other expertise
Windows Server System MVP – SMS

http://www.scug.be/blogs/sccm/default.aspx

http://www.linkedin.com/in/kimoppalfens