Friday, 23 May 2014

SCCM - Task Sequence Fail - Windows failed to start. A recent hardware of software change might be the cause.


Issue:
When PXE booting a machine, immediately after the Task Sequence has loaded it fails and the following error message pops up:

"Windows failed to start. A recent hardware of software change might be the cause. To fix the problem"


On the SCCM server, you may have also opened up the smspxe.log file (c:\windows\syswow64\ccm\logs\smspxe.log) and seen the following error message:

"Failed to read PXE settings. The system cannot find the file specified ... error 800700002"
as well as

"PCE provider failed to process message. Unspecified error"




 Fix:
1] Start with the classics, restart the WDS Service and, if you like, bounce the SCCM box
2] On the SCCM server, navigate to c:\windows\temp\PXEBootFiles and delete all the contents found therein. Once you've done this you should be able to kick off the PXE boot on the client machine and the Task Sequence should run!


Wednesday, 14 May 2014

Windows 7 + 8 Mapped Drives Disappear

Issue:
Mapped drives, even when set to persist, will disappear after a reboot. This issue occurs regardless of how the drive was mapped, be it through Windows Explorer "Map Network Drive" or through the 'net use' and the cmd line.

Cause:
Assuming you haven't got some sort of Group Policy setting which prevents the caching of domain credentials (e.g. Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\”Network access: Do not allow storage of credentials or .NET Passports for network authentication”) then chances are it's a ghost in the machine.

Resolution:
Ensure that you've checked the following box from the Organise > Folder Options  

 


Reboot your machine
Log in and map the network drive
With a bit of luck it should now persist!

Wednesday, 7 May 2014

File Storage and Access - CIFS, NFS, SMB, NTFS


File Storage and Access

   Below is a very basic introuction to the various options availbe to those who wish to remotely access their data. This is only intended to give a brief outline of the various protocols which can be utilised in pursuit of remote file access......

SMB – Server Message Block

SMB is a file sharing protocol that was invented by IBM in the 1980s. It’s purpose is to allow computers to read and write files to a remote host over a local area network (LAN). The directories on the remote hosts made available via SMB are called “shares.”

CIFS – Common Internet File System

NAS file level protocol. Used in Windows. Works on a client/server relationship. CIFS is a particular implementation of the SMB protocol.

NFS – Network File System

NAS file level protocol. Used in Linux. Works on a client/server relationship.

NTFS – New Technology File System

This is not actually related to any of the above since they are all ways of remotely access data. New Technology File System on the other hand is the file system Windows uses for storage. NTFS has nothing to do with remote access of files/shares.

 

iSCI vs NFS

The most predominant difference between iSCSI and NFS is that iSCSI is block level and NFS is file based. With NFS, the filesystem is managed by the NFS server, for example, a Netapp Storage System and with iSCSI the filesystem is managed by the guest Operating System. Neither is really better than the other. Block based protocols where the guest os manages the filesystem allows you to take advanced of tools like snap manager for (exchange, oracle, SAP, sql, etc). To put as simply as possible with snap manager, the guest OS, application and storage system all work together and ensure the file system is in a consistent state when snapshots occur. On the other hand, typically with NFS, 50 or more virtual machines live inside the same volume and are deduplciated against each other. Deduplication on a volume with a single lun inside of it only finds duplicate blocks within a single filesystem. It is possible to place more than one iSCSI lun inside the same volume, but best practice is a 1-1 relationship.

 

NFS vs CIFS

They are both NAS file level protocols. CIFS is the Windows flavour and NFS is for Linus/Unix, but there is some degree of interoperability. Samba is a linux/unix implementation of a CIFS server, and it is possible to mount NFS storage on a windows system with a UNIX utilities package. The ACL translations can be tricky and not fully functional when crossing OS. Netapp does some nifty stuff to separate the protocol layer from the filesystem that allows you to do cool things like share the same volume out through CIFS and NFS. Again, some gotchas with ACLs. You want to pick NTFS or unix ACLs, there is a mixed mode, but it is...well, kind of an administrative headache in my opinion. Don't use mixed mode unless you know what you are getting into and have a specific use case.

 

SMB vs CIFS

Essentially this is one in the same. The two are interchangeable not only in discussion, but also in application – i.e., a client speaking CIFS can talk to a server speaking SMB and vice versa. Why? Because CIFS is a form of SMB. In today’s workplace environment, chances are you’ll want to use SMB as the CIFS implementation of SMB is rarely used these days. Under the covers, most modern storage systems no longer use CIFS, they use SMB 2 or SMB 3. In the Windows world, SMB 2 has been the standard as of Windows Vista (2006) and SMB 3 is part of Windows 8 and Windows Server 2012.