skip to main |
skip to sidebar
Consider the following scenario. You're running SCCM 2007 SP2 with R2 (or R3 for that matter) on Windows Server 2008 and want to deploy Windows 7 cliënts. When you try to import the drivers for your Windows 7 workstations into SCCM you might run into the issue when some drivers give the error:
The selected driver is not applicable to any supported platforms
You'll only get this error when you're trying to import drivers that are Windows 7 exclusive. This issue is due to the fact that SCCM uses the internal methods of handling inf files and Windows Server 2008 does not 'know' of Windows 7 yet. Install the following hotfix from Microsoft to fix this issue.
http://support.microsoft.com/kb/978754
Remember, this is not applicable on Windows Server 2008 R2 but only for windows Server 2008.
Hope this helps.
Regards,
Stefan Hazenbroek
What if you created a certificate infrastructure, sized it according to the requirements known at the moment and a new project comes along that requires a certifcate services Database and log that is three times the size of the original one, so it doesn't fit onto your sized harddisk. In alot of scenario's it's possible to expand the disks (using vmware, xenserver or hyper-v this is quite easy), but when you're using physical servers it's not so easy.
Or, maybe, when you installed AD CS you forgot to move it from c:\windows\system32\Certsvc. No worries, it's quite easy to change it.
In this short blogpost I'll explain how to move the certificate services database and log location after AD Certificate Services has been installed.
1. Prepare the disk, LUN or whatever you have in mind for your database and log. Ideally both will be placed on separate disks for performance reasons. Create the path for the database and log. In case it'll be placed on one disk I always assume CertDB for the database and CertDB\Logs for the logs, to keep things tidy.
2. Stop the AD Certificate Services service by running net stop certsvc from an elevated command prompt or by right clicking and selecting Stop service in the Services MMC.
3. Copy the database and the logs to their new location.
4. Open the registry editor by starting regedit and browse to HKLM\System\CurrentControlSet\Services\CertSvc\Configuration.
5. Edit the following entries:
DBDirectory (default is C:\Windows\System32\CertLog\..., change it to your new databasedir)
DBLogDirectory (default is C:\Windows\System32\CertLog, change it to your new logdir)
DBSystemDirectory (default is C:\Windows\System32\CertLog, change it to your new databasedir)
DBTempDirectory (default is C:\Windows\System32\CertLog, change it to your new databasedir)
6. Start the certification authority again by running net start certsvc from the commandline or by right clicking the AD Certification Services service and choosing Start. From this moment your DB and log should be running from the new location.
7. Verify it is running from the new location. You can do this by opening up the certification authority MMC. Right click on the name of your CA and choose Properties. Choose the tab Storage. The tab should look like this, with the location of your DB and Logs on a perhaps different drive/letter.
Hope this helps.
Regards,
Stefan Hazenbroek
Previous Versions (or, Volume Shadow Copy Service) is a very powerful way of letting users manage their own files in an enterprise environment. One issue however, especially for department-shares, is the possibility to restore a file using Previous Versions. There is no pretty way to disable this using a group policy or something similar, but it IS possible.
By default it is possible for users to restore files. By following the next steps you can turn this off so that only Open and Copy can be used.
- Fire up the registry (regedit).
- Browse to: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer to turn it on or off for the current user or HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer to turn it off for the local machine. I suggest turning this off on a user basis, so that your IT Administrators can still manage this if needed.
- Create a new REG_DWORD with the name NoPreviousVersionsRestore. The value for this entry is 1.
It isn't needed for the users to log off and on again for the setting to be put into place. I suggest putting this in a group policy preference for ease of management.
Hope this helps.
Regards,
Stefan Hazenbroek
It can happen to everybody. A DFS Link gets deleted in the wrong way by accident, and now it's stale sources are being a burden in your DFSroots directory. This can happen due to errors in namespace replication or unclean shutdowns. The directory cannot be opened or manually deleted, so how can we get rid of this?
When you try to open the directory you'll get the following error:
It makes sense to get this error, because DFS make a sort of junction point on your fileserver to relocate you to the real point. When you try to delete the folder you'll get this error:
When a DFS link gets created, a reparsepoint is created in the DFSroots directory. This is a link to the original directory. Also, see: http://msdn.microsoft.com/en-us/library/aa365503(VS.85).aspx for more information.
This reparsepoint is also what's causing the error. Normally, if you try to open a reparsepoint (like AppData in Windows 7 is), you'll get redirected to the original directory. In the case of DFS this works somewhat different, because the original directory isn't located on the same server.
To fix this we have to take some steps. First, open up Command Prompt and browse to your DFSroots directory. In my case this is C:\DFSroots. Open up your DFS namespace and look at the folder contents. This folder is what's being published when an user accesses your DFS namespace.
Above are the folder contents of the DFSroots folder in my test environment. Top Secret is a stale folder, so I'd like to delete this. Windows contains a tool called fsutil that can help us reach this goal. Type: fsutil reparsepoint query \\. In my case this would be fsutil reparsepoint query "C:\DFSroots\Public\Top Secret". Remember to enclose your query with quotes ("") when your name contains spaces.
The result should look alot like the following:
As you can see within the Tag Value, this reparsepoint is created by/for Microsoft DFS. Now, we're gonna delete this reparsepoint so our view of the namespace will be nice and clean again. Type: fsutil reparsepoint delete \\ and press Enter. Again, mind the quotes.
In this case the rule is: No result is good result. When you get a blank line your command succeeded. When you try to remove something that's not a reparse point you'll get an error looking a lot like the following one:
This means the reparse point is already deleted or you're giving in the wrong directory in your command line.
Hope this helps in keeping your DFS environment clean and tidy.
Regards,
Stefan Hazenbroek
A short while ago a question was asked on the Technet Forums regarding folders not being shared as expected after a reboot. This specific issue was in regard to BitLocker, but this same issue applies when the folders are being hosted on a volume that's connected through a SAN (Fibre/iSCSI and such)
After being able to answer the question I thought I'd post a short blog article in regard to this issue, because it's a very common issue and not very well documented.
Issue
When you reboot your server all shares that are hosted on a SAN, on a BitLocker protected volume or anything other that needs a service in order to ensure it's availability. After restarting the Server service these shares come available, but there are no clear errors in the eventlog that states something is wrong.
Resolution
The issue is due to the BitLocker (or the service that connects your FC/iSCSI devices) service not being started yet when the Server service is started. When the server service is started, it tries to locate all folders to share and disregard the ones that aren't reachable. Because the service required is started shortly after, you won't notice any apparent issues until you investigate them.
Luckily this issue is quite easily fixed by editing a value in the registry. I'll explain this by showing an example.
1. First, open up services.msc.
When you look at the screenshot below, you'll see the shortname of BitLocker Drive Encryption. Write down this name or save it somewhere, we'll need it later.
2. Open regedit (Start, Run, type: regedit)
Browse to Hkey Local Machine\SYSTEM\CurrentControlSet\LanManServer
When you look in the key you'll see a value called DependsOnService. In my case this value is filled with SamSS and Srv. Open up this value.
As you can see, both services that need to be started in order to start the Server service are SamSS and Srv. Place the cursor after Srv and press Enter. Now type bdesvc (or the name of your required service you located in Step 1) and press Enter again. After filling in the value it should look like this:
Press Ok and reboot your server.
After a reboot your shares will be available directly from boot as they should be. Remember to remove the added service when you disable BitLocker again or remove the disks from SAN, otherwise the Server service won't be able to start.
Hope this helps.
Regards,
Stefan Hazenbroek
